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If this isn't APRIL.. 
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POLICY: PASCAL NEWS 



(15-Sep-80) 



* Pascal News is the official but informal publication of the User's Group, 

* Pascal News contains all we (the editors) know about Pascal; we use it as 
the vehicle to answer all inquiries because our physical energy and 
resources for answering individual requests are finite. As PUG grows, we 
unfortunately succumb to the reality of: 

1. Having to insist that people who need to know "about Pascal" join PUG 
and read Pascal News - that is why we spend time to produce it! 

2. Refusing to return phone calls 'or answer letters full of questions - we 
will pass the questions on to the readership of Pascal News. Please 
understand what the collective effect of individual inquiries has at the 
"concentrators" (our phones and mailboxes). We are trying honestly to say: 
"We cannot promise more that we can do." 

* Pascal News is produced 3 or 4 times during a year; usually in March, June, 
September, and December. 

* ALL THE NEWS THAT'S FIT, WE PRINT. Please send material (brevity is a 
virtue) for Pascal News single-spaced and camera-ready (use dark ribbon and 
18.5 cm linesT) 

* Remember: ALL LETTERS TO US WILL BE PRINTED UNLESS THEY CONTAIN A REQUEST 
TO THE CONTRARY. 

* Pascal News is divided into flexible sections: 

POLICY - explains the way we do things (ALL-PURPOSE COUPON, etc.) 

EDITOR'S CONTRIBUTION - passes along the opinion and point of view of the 
editor together with changes in the mechanics of PUG operation, etc. 

HERE AND THERE WITH PASCAL - presents news from people, conference 
announcements and reports, new books and articles (including reviews), 
notices of Pascal in the news, history, membership rosters, etc. 

APPLICATIONS - presents and documents source programs written in Pascal 
for various algorithms, and software tools for a Pascal environment; news 
of significant applications programs. Also critiques regarding 
program/ algorithm certification , performance , standards conformance , 
style, output convenience, and general design. 

ARTICLES - contains formal, submitted contributions (such as Pascal 
philosophy, use of Pascal as a teaching tool, use of Pascal at different 
computer installations, how to promote Pascal, etc.). 

OPEN FORUM FOR MEMBERS - contains short, informal correspondence among 
members which is of interest to the readership of Pascal News . 

IMPLEMENTATION WOTES -reports news of Pascal implementations : contacts 
for maintainors, implementors, distributors, and documentors of various 
implementations as well as where to send bug reports. Qualitative and 
quantitative descripjtions and comparisons of various implementations are 
publicized. Sections contain information about Portable Pascals, Pascal 
Variants, Feature-Implementation Notes, and Machine-Dependent 
Implementations . 
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Pascal Users Group 
P.O. Box 4406 
Allentown, Pa. 18170-4406 USA 

**Note"** 

We will not accept purchace orders. 

Make checks payable to: "Pascal Users Group", drawn on a U.S. bank 
in U.S. dollars. 

See the Policy section on the reverse side alternate address if 

you are located in the Australasian Region. 

Note the discounts below, for multi-year subscription and renewal. 
The U. S. Postal Service does not forward Pascal News . 

USA Europe Aust . 



[ ] 1 year $10. $14. A$ 8. 

Enter me as a new member for: 

[ ] 2 years $18. $25. A$ 15. 

Renew my subscription for: 

[ ] 3 years $25. #35. A$ 20. 



! ! 

Send Back Issue (s) 1 ! 

My new address/phone is listed below 

Enclosed please find a contribution, idea, article or opinion 
which is submitted for publication in the Pascal News. 

Comments : 
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! $ 
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NAME 
ADDRESS 



PHONE 
COMPUTER 



DATE 



JOINING PASCAL USERS GROUP? 



- Membership is open to anyone: Particularly the Pascal user, teacher, 
maintainer , implementor , distributor, or just plain fan. 

- Please enclose the proper prepayment (check payable to "Pascal User's 
Group"); we will not bill you. 

- Please do not send us purchase orders; we cannot endure the paper work! 

- When you join PUG any time within a year: January 1 to December 31, you will 
receive all issues of Pascal News for that year. 

- We produce Pascal News as a means toward the end of promoting Pascal and 
communicating news of events surrounding Pascal to persons interested in 
Pascal. We are simply interested in the news ourselves and prefer to share 
it through Pascal News . We desire to minimize paperwork, because we have 
other work to do. 



- American Region (North and South America), and European Region (Europe, 
North Africa, Western and Central Asia) : Join through PUGUSA 

- Australasian Region (Australia, East Asia - incl. Japan): PUG(AUS). Send 
$A10 . 00 per year to: Pascal Users Group, c/o Arthur Sale, Department of 
Information Science, University of Tasmania, Box 252C GPO, Hobart, Tasmania 
7001, Australia . International telephone: 61-02-23 0561 x435 



PUG (USA) produces Pascal News and keeps all mailing addresses on a common 
list. Regional representatives collect memberships from their regions as a 
service, and they reprint and distribute Pascal News using a proof copy and 
mailing labels sent from PUG (USA). Persons in the Australasian Region must 
join through their regional representative. People in other places please 
join through PUG (USA). 

RENEWING? 

- Please renew early (before November and please write us a line or two to tell 
us what you are doing with pascal, and tell us what you think of PUG and 
Pascal News . Renewing for more than one year saves us time. 

ORDERING BACK ISSUES OR EXTRA ISSUES? 

- Our unusual policy of automatically sending all issues of Pascal News to 
anyone who joins within a year means that we eliminate many requests for 
backissues ahead of time, and we don't have to reprint important information 
in every issue--especially about pascal implementations! 

- Issues 1 .. 8 (January, 1974 - May 1977) are out of print . 

- Issues 9 . . 12 (September, 1977 - June, 1978) are available from PUG(USA) all 
for $15.00 and from PUG(AUS) all for.$A15.00 

- Issues 13 .. 16 are available from PUG(AUS) all for $:A15. 00; and from 
PUG (USA) all for $15.00. 

- Extra single copies of new issues (current academic year) are: $5.00 each - 
PUG (USA); and $A5.00 each - PUG(AUS). 

SENDING MATERIAL FOR PUBLICATION? 

- Your^ experiences with Pascal (teaching and otherwise), ideas, letters, 
opinions if notices, news, articles, conference announcements, reports, 
implementation information, applications, etc. are welcome. Please send 
material single-spaced and in camera-ready (use a dark ribbon and lines 18.5 
cm. wide) form.. 

- All letters will* be printed unless they contain a request to the contrary. 



APPLICATION FOR LICENSE TO USE VALIDATION SUITE FOR PASCAL 



Name and address of requestor: 

(Company name if requestor is a company) 



Phone Number: 



Name and address to which information should 
be addressed (Write "as above" if the same) 



Signature of requestor: 
Date: 



In making this application, which should be signed by a responsible person in the 
case of a company, the requestor agrees that: 

a) The Validation Suite is recognized as being the copyrighted, proprietary prop- 
erty of R. A. Freak and A.H.J. Sale, and 

b) The requestor will not distribute or otherwise make available machine-readable 
copies of the Validation Suite, modified or unmodified, to any third party 
without written permission of the copyright holders. 

In return, the copyright holders grant full permission to use the programs and doc- 
umentation contained in the Validation Suite for the purpose of compiler validation, 
acceptance tests, benchmarking, preparation of comparative reports, and similar pur- 
poses, and to make available the listings of the results of coiripilation and execution 
of the programs to third parties in the course of the above activities. In such doc- 
uments, reference shall be made to the original copyright notice and its. source. 

Y Distribution charge ; $50.00 

X Make checks payable to ANPA/RI in US dollars drawn on a US bank. 
Remittance must accompany application. 

Source Code Delivery Medium Specification: 

9-track, 800 bpi, NRZI, Odd Parity, 600;' Magnetic Tape 

( ) ANSI-Standard 

a) Select character code set^ 

( ) ASCII ( ) EBCDIC 

b) Each logical record is an 80 character card image. 
Select block size in logical records per block. 

( ) 40 - ( ) 20 ( ) 10 

( ) Special DEC System Alternates: 
( ) RSX-IAS PIP Format 
( ) DOS-RSTS FLX Format 



Office use only 

Signed 
Date 



Richard J. Cichelli 
On behalf of A.H.J, Sale & R.A. Freak 



Mail request to: 

ANPA/RI . . 
P.O. Box 598 
Easton, Pa. 18042 
USA 

Attn: R,J. Cichelli 
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Editor's Contribution 



NEW ADDRESS 

Yes, in my continued effort to bring you better service, (read 
this as: I can not do all the work effectively!) I have found 
someone else (read: sucker) to take over the PUG mailing list. I 
am sure that this will increase the satisfaction level for this 
task 100%. this will take a great load off of my back and allow me 
to devote all of my time to editing and publishing Pascal News . 

LATE 

I thought April first (April Fools Day) was an appropriate target 
date for this issue of Pascal News l I apologize for the tardiness, 
but my work (I have a real joh that pays the bills) and the many 
pressing problems and issues of PN got in the way. I had to solve 
the PUG Europe problem, and try to gather as much as I could 
concerning the final vote on the ISO standard. 

FUTURE OF PUG IN EUROPE 

It took me more than a few months to correct the festering 
problems in Europe surrounding Pascal News . The previous 
coordinator was sinking under the mire of ever increasing job 
responsibilities as well as the editorship of clearly the best 
journal dealing with practical software implementation. (SP&E) As 
a result, the european region suffered, from lack of attention. 
This is oven PUG cares. Please send your "job well done's" to 
David in Southampton, and send your complaints to PUGUSA. We will 
be handling all but the Australasia Region from the US. Please 
read the new APC carefully for policy and price changes. We will 
be mailing by surface mail to the UK and Europe, but I have . been 
assured by the USPS that it should take no more than a month. I 
have been asked if I would mail by air for an extra surcharge. The 
answer has to be no, at this time. PUG can just not afford the 
special processing and handling that this would be required for 
two different types of mail. Sorry! 



STANDARDS 

Another delay was the standards effort. There is so much going on 
in the standards arena that we just could not afford to miss it. I 
think it was worth it. Over half of this issue is devoted to the 
vote on the ISO standard for Pascal (7185) . Jim Miner has done 
another fine job. 
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THIS ISSUE 



Now the good news! We have another jam packed issue. I think you 
will recognize out book reviewer this issue. He is an "occasional" 
contributor to PN. And I hope you will get a chuckle from our 
"sister" publication PUG PRESS. Andy Mickel brings this little gem 
to us. The other HERE. and THERE article is a real puzzle. It came 
to me just as you see it!? 

The application for this issue was so good I could not miss 
publishing it. It is a Pascal to EMl pseudo code compiler by 
Andrew Tanenbaum. Its a real beauty. But it was sooooo big I could 
not publish it all ... yet. This issue contains the definition of 
the assembler language that is output and also an interpreter 
which serves as the EMI machine definition. Issue 22 will contain 
the program text for the EMI Pascal compiler. I hope everyone 
reviews the documentation and the' code, even if they do not need 
the compiler. It is a fine example of elegant design and 
implementation using the language Pascal. Also included in the 
APPLICATIONS section is an article by Jeff Pepper om the 
implementation of extended precision integer arithmetic. A fine 
job . 

The ARTICLES section contains a thought provoking extension to the 
read/write subroutines by David Rowland. Lets hear a response from 
the members. And finally Maragret Kulos has contributed a very 
comprehensive article comparing OMSl-1 Pascal and The Swedish 
Pascal compiler. There is a great deal of interest in these two 
compilers for the PDP-11. I hope this provides some answers* 

All in all, a great issue. More to come on EMI in issue #22. 

Hope you like it! 




4^ 4^ 4^ 4^ 4^ 4^ 4^ ^L/ ^L>' ^L/ ^L^' 

'^^r "^r^ '^r ''■^ '^r "'^r '■^ "b^ ''^r "^r 



Here and There With Pascal 



BOOK REVIEW 

The Pascal Handhook hy Jacques Tiherghien 

500pp, 270 Illustrations, SYBEX, Berkeley 
(1980) $US14.95 (paper edition only), 
ISBN 0-89588-053-9. 



Overview 

This is not a Pascal textbook; it is something very different . Perhaps the 
most succint description is that it is a Pascal lexicon: a sort of 
all-purpose reference manual. It is organized around entries keyed by an 
appropriate Pascal word (eg if, scope, writeln) arranged in alphabetical 
order. Each entry- takes up one or more whole pages, and the standard sub- 
headings are SYNTAX, DESCRIPTION, IMPLEMENTATION-DEPENDENT FEATURES and 
EXAMPLE. The relevance of the entry to Standard Pascal and a number of 
particular implementations (HPIOOO, CDC, OMSI-1, Pascal/Z and UCSD Pascal) is 
encoded into the entry. 

Thus the book is meant to be used as a dictionary to look up difficult points 
or to find out what some usage in a program you have received really means. 
As such, it follows a lot of reference manuals which are similarly structured 
(eg the B6700/7700 Pascal Reference Manual). 

However, since Pascal is a small language with not very many things needing 
to be remembered, it needs to be asked why a lexicon of 500 pages is needed? 
Examination of the book indicates that its main purpose seems to be to 
document extensions and differences between implementations. Thus, since its 
topic is the union of all the quirks of 5 implementations, it has grown to 
this rather large size. 

Target and reality 

So much for the target; how does the book match up to it in reality? The 
answer seems to be that it does a reasonably good job of documenting what 
exists, but that it does not measure up to the very exacting standards that 
such an ambitious project warrants. The standard of accuracy against which a 
dictionary is judged is much higher than that appropriate for textbooks, 
which a few lapses can be tolerated or justified on tjie grounds that pedantic 
accuracy would impede learning. 

The slips in the book are far too numerous to detail (a list is being sent to 
the author), and a few examples will have to suffice. Dipping into the entry 
for the reserved word for is probably the richest source of examples. 
Faults which should be mentioned are: 

(1) An "equivalent flow-chart" is given. The sense of defining a high- 
level construct such as while in flow-chart terms is questionable at 
the best of times, but for the complex for-statement it is extremely 
unfortunate in that it might make people think the flow-chart is right. 
It isn*t. 

(2) The prohibition on changing the value of the count variable is not 
mentioned . 

(3) The limitations on what a count variable can be (only a local simple 
variable) are not mentioned.. 

(i+) The correct restriction of the HP-1000 implementation is considered to 
be an implementation-dependent feature, whereas the corresponding flaw 
'in the J&W/CDC implementation is not mentioned. 



(5) The failure of many of these implementations to enforce the 
requirements of the for-statement is not mentioned; indeed for four 
implementations the entry is None known for implementation-dependent 
features . 

(6) The possibility of the statement failing to terminate (incorrectly) for 
some limit values in the OMSI and UCSD implementations is not 

documented. ~ _^ 

(7) The statement is made that The A and B parameters may not be modified d> 
hy the statement in the loop. This is simply incorrect, though it is ^ 
true to say that the loop limits are determined on entry to the loop. ^ 

Perhaps this is the worst case to show, but a few more examples will suffice ^ 
to show that the problem is not isolated. The syntax for MARK sho.ws that 
this non-standard jJrocedure takes a parameter which is an integer 
expression. MAXINT is incorrectly described as determining the positive 
limit of representable integers (which it may be only coincidentally) . The 
syntax for CASE statements is incorrect. And so on. 



CO 



General issues 

Therjs are two major deficiencies in this book which deserve comment. First 
is the lack of formal definitions , and indeed the appearance of only a few 
English descriptions that resemble the actual requirements of Pascal. The 
author claims to be talking about Pascal (presumably the standard variety) as 
well as the others, but there is simply no basis for comparison if the reader 
cannot find out what sets, for example, are really supposed to be. 

The second is the mystifying omission of any reference to the Pascal 
Validation effort. If one of the purposes of the book is to aid programmers 
who wish to write portable Pascal programs, then it is difficult to 
understand why the author did not carry out validation tests on the five 
compilers he regards as important, and print the results in a second section 
of the book. It would have added significantly to the value of the book as a 
reference . 



Minor issues 

Regrettably, once again it is necessary to point out that capitals were 
designed for carving into stone, not for ease of reading. This book 
perpetuates the habit of printing programs in capitals, with consequent 
loss of legibility. 

It is difficult to deduce the author's criteria for choosing which topics to 
omit or include. To illustrate this, note that the UNIT feature of USCD 
Pascal, together with the corresponding USES, INTERFACE and IMPLEMENTATION 
reserved words, is not treated in the book, apart from a mention, despite 
their undoubted importance in use. On the other hand, such trivia as a pre- 
defined function EXPIO in OMSI Pascal takes up 2 pages. 

> 

Directing another comment to the publisher rather than the author, one ^ 
wonders why the tremendous amount of white space in the book was tolerated. 

A little care in layout (perhaps two entries per page; perhaps denser ^ 

printing) would have halved the number of pages, and perhaps reduced the 

price. 



Summary view 



Despite the criticisms made above-, I believe the book would be useful to 
programmers who have to cope with Pascal programs which were developed on 
different systems or in different dialects. The level of detail and accuracy 
of information is not as high as it could be, but nevertheless the book has 
no competitors. 

I doubt that it will be of much use to programmers learning Pascal, still 
less beginners at programming, because it is too difficult to see what is 
really Pascal and what is "extension". And of course, dictionaries are 
simply not meant to be read through. 



A. E, J. Sale 



BOOK REVIEW 

INTRODUCTION TO PASCAL 
- including UCSD Pascal 

by Rodnay Zaks 

320pp, 100 illustrations 

Sybex, Berkeley (1980) US$12.95 (Paper Edition only) 
ISBN 0-89588-050-4 

Reviewed by A. H.J. Sale, Sandy Bay, Tasmania. 



Overview 

On receiving a. book which proclaims that it will teach you a programming 
language, I conceive that most reviev/ers will groan and wonder what new there 
is to say. The more so if the language is a popular one, such as BASIC, 
Fortran, COBOL, or Pascal. For many educational book writers are 
plagiarists, and after the fifth to tenth version of the same ideas, my eyes 
get weary and the text fuzzy... 

To start with, then, it is a pleasure to be able to write that Rodnay Zaks 
book is somewhat different from the run-of-the-mill Pascal books. Firstly it 
has a definite target readership, and is addressed to them. Dr'Zaks' book is 
well-suited to irticrocomputer enthusiasts and programmers who want to learn a 
bit about Pascal but have no immediate intention of using it professionally. 
The exposition is gentle, fairly easy to read, and liberally interlaced with 
reading examples. 

To enhance its value to such readers, Dr Zaks has decided to include material 
on one popular variant of Pascal in the microcomputer field: UCSD Pascal. 
This is interspersed throughout the book in clearly labelled sub-sections. 

Secondly, the book has a good collection of examples, and they are not 
exactly the same examples you find in other textbooks! ' Learning a language 
is always easier if you can read-it (and read a lot of it), since then you 
discover samplers (or templates) that you can modify to your own purposes, 
and thus gi'adually discover typical programming paradigms of that language. 



The presentation is traditional, and there are no surprises. The chapter 
headings are: Ba-'c Concepts, Programming in Pascal, Scalar Types and 
Operators, Expressions and Statements, Input and Output, Control Structures 
Procedures and Functions, Data Types, Arrays. Records and Variants Files 

^^^^ ^^'^ Pascals, Program Development (15 'in 

all) followed by 12 Appendices including answers- to selected exercises 



S hortcomings 

In my opinion, the book is not likely to be widely used as a text in 
tertiary courses, for several reasons. Most importantly, it is very light on. 
the concepts of Pascal and Dr Zaks treats of the language simply as another 
Fortran or BASIC. Instructors trying to get across the important advances in 
knowledge about computing will not forgive the lack, whereas readers using it 
as a self- tutorial almost certainly wouldn't notice the deficiency. Less 
important, but still relevant, is the typical American verbosity in this • 
kind of book. 

To illustrate the conceptual treatment, observe that 6 pages (pp 135-1 MO) deal 
with enumerated types and subranges, and 11 pages (pp247-257) for sets. 
Other data structuring methods seem to fare better, but this appearance 
disappears on close examination. For example the array chapter contains 
39 pages, but ^ pages are devoted to a matrix addition program, 16 pages to 
a sorting program, and 8 pages to UCSD features (including UCSD strings which 
are not arrays at alll), leaving 11 pages of discussion of the syntax and 
semantics of arrays^. The low-level obsession v/ith flow of control is very 
obvious in this book. 

A reviewer cannot pretend to check every program and statement in a book such 
as this, but I was pleased to note few errors or half-truths in "Introduction 
to Pascal". Notable amongst the omissions, however, are references to the 
axiomatic definition of Pascal (surely one of the most important sourcesl) 
and to the draft ISO Standard for Pascal. These omissions seem to be related 
to the book's orientation towards small computers and relatively naive 
programmers. 

In spite of the great care put into this book (its technical presentation is 
excellent except for the blunder of printing program text in capitals) , I had 
to come to the conclusion that the inclusion of UCSD Pascal in it is a 
mistake. The book is predominantly about "Standard Pascal", and purchasers 
who hope to learn something about UCSD Pascal that is not in the UCSD and 
SofTech manuals will be disappointed. It seems that the UCSD material acts 
as textual clutter, even if its inclusion on the cover sells more copies. 



Summary 

"Introduction to Pascal" by Dr Rodnay Zaks is a useful soft-cover book that 
will probably be useful to people trying to learn Pascal by themselves, due 
to the many examples. However, it will lead them up to the point of 
programming usint„ Pascal , but thinking in traditional ways. Many of the 
insights and productivity improvements will require extensive further 
experience, but perhaps that is inevitable. 
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Even -vfith all the snow on the ground, SPRING IS IN THE AIR! : ! I 
This is a good time to rememher to "bring your dog's shots up to date 
and don't forget ahout hesLrt-worm. 

One of Marianne's Pug Family has passed away in early February. 
Helen Landon had only had her PUGS for Zi years, but she truly lo-ved 
them . iHer love for all animals was a driving force in her life , and 
she will be missed. The family has requested memorials to Pet Haven 
or American Cancer Society. 

Tracy Cunningham has a new little girl PUG named Miss Josie Posie 
Penelope. The day "before Christmas she was "brought home at the tender 
age of zi weeks. (This should "be a reminder that not all breeders are as 
concerned for the dog's welfare as they should be. There is no excuse for 
selling a dog at this age for monatary gain. Remind people who are looking 
for puppies that they should be eating from a dish, and should be able to 
get along without their Mama and litter mates before they are taken home.) 

Mr. and Mrs. Don Coen of South St. Paul are soon to be getting a new 
baby boy PUG. They recently lost a 13 year old PUG, 

Mr. and Mrs. Don Donaldson of River Falls, Wise, became owners of 
a male PUG at Christmas time. They bought him from Rachel Pishcher; he 
was at the Pug Party last fall as a puppy. 

Mr. and Mrs. Joe Jenareo of Minot brought home a new female PUG in 
December. They have an eight year old male and are also looking for 
another male. 

The John Kerschner Family recently "bought an eight month old PUG 
puppy from Dorothy' Justad. 

The John Healy Family would like to know some of the names that 
have been given to the pugs. So we thought it would be fun to have a 
"PUG NAME CONTEST." The contest will be based on the registered and/or 
call names our PUG people have named their PUGS (past and present). 
Some of the catagories will be x most unusual, most "beautiful, most 
interesting, most common, and most- humerous. To enter the contest, please 
write or call Maryanne before June 1, I98O. All entrants will be mentioned 
in the next newsletter. 

We have it on good authoiMty that Pandy Wenz has visited Chipper 
Justad at his home. Early May will tell the tail ! ! ! ! 
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Dorothy Justad is proud to announce the arrival of 1 
Woodcrofts Foster Fordyce arrived February 12th (the one and only) 



Siret AKC & CKC ptd in Bermuda Ch. Shef fields Shortening Bread 

(better known as Chipper) 
Damt Sugar Plum Jen I 



WANTED - Small PUG Stud to breed with the Classiest Bitch in Town 
Stud must be experienced yet gentle, loving, and discreet. 
Contact- Ron or Marlys Hampe ( 6l2 ) -89 O^i^lifl 

Pet In^'s? %Zl^^''L'^^'^ f?^^?v*• St. Paul 551051 is the manager at Sherwoc 
Pet in St. Paul. He would like a male pet PUG at a reasonable price. 

Eunice Thorson; 536 1st St., Proctor, Mri. 558l0j -recently lost her 
fourteen year old PUG. She would like another girl puppy or older PUG? 



m 

CO' 



^^^T. ^? ^^°^^3r Justad for the wonderful article on getting 

in showing IugI "^^^ ^^"^^^ you^nterfstec 

"PUG ?Fn??F"^STL!^^fJ?^-''^w that you would like to share with fellow 
PUG PEOPLE please let us know. -Deadline for the next newsletter is 
June 1, I98O, Just call or write Maryanne, and we'll get your news in 
the next issTie of PUG PRESS. ^ 



EAVE A HAPPY SPRING 





Maryanne Johnson 
Henrietta Wenz 
Patti Sue Selseth 





Dear Newsletter enthusiast, the following is a list of subjects that are 
likely to be examined in the upcoming newsletters. If you feel like 
it, please respond to any of the subject matter, adding suggestions, 
visions, or other comments. Bits of any incoming communication are 
likely to be recycled into the newsletter at some date. This being the 
first newsletters, the form may change from issue to issue, but my idea 
initially is to have each letter be a theme examining some proponent of 
the hypothetical floating sea city, of which we can all be a part. 

a. the spiral method of accretion 

b acquiring the necessary elements off the land: going into the 

recycling aspects of the project, recycling of cars, refrigerators, 
machines for the conducive materials , and also papers and (liquified) 
plant matter, for the papier mache structures. 

c. A deeper tripping out on paper machait: how it can be used to 
invoke peoples' minds as to the process of accretion, selecting 
varieties of forms which scintillate. Drawings can be included of 
terrestrial motifs, walls, time capsules, zoomorphic borders of 
gardens, rises, walkways, spontaneous expressions of color and 
form. 

d. aspects of energy acquisition and usage: Solar, wind models, under- 
water exploits; shai ing- concepts , valuation. 

e. PI ant life likely to evulve, and the natares of \. "».rgent ecosysceir 
including overlappings , and new symbioses. 

f . Food to be grown, produced, specialty items for shipping away, into 
the land: Pickles, sweets, noted cheeses, pastries, modes of eating; 
availability jof different substances . 

g. Separation of thirds of spaces: industrial/mercantile/co-operative; 
common/state-owned; and home spaces, privately ruled and operated. 

h. Varieties of social forms, explorations of likely- traditions to be 
fused for propulsion into pyremusical ambidextrous ly mobile batteries. 
Cultures to be examined including refugees, aliens, star-struck, 
dropped out, mutating, change-oriented. 

i. Blasting of t'ae closed-ended systems, reiterating the expansive 
potentials inaerent in futuristic thinking: an invitation to 
recent explosions. 

j . The iimer workings and displayed aspects of the water system in the 
structure. Designs for waterfalls, ponds pools, streams, bathing, 
plant feeding, recirculation, distillation. 

k. Art- and Extrapolitical-aspects of lifestyles emerging on the sea. 

Options for peoples' expressions in career, craft, vocation, activities 

1, An examination of the effort to create groups of three melting, softing 
tetras , to meet and merge on the high seas, producing the interior 
lagoons and flatlands. Also known as triangulation, the tendencies of 
groups of threes to balance and stability. ' 

m. Diagrammatic explanations of the various levels, including shipping 

ports, flotation devices, fluxuating shores, and sky-high properties. 
Proportions of spaces allotted *to playgrounds, bycicle loops, 
orchards, cottages, mist gardens, arboretum/terminal stands, geodescic 
elevating modules, and sky light sculptures of varying densities 
will be suggested, examined, detailed. 

n. Something to attract transient visitors: vacation playgrounds. 

There are fantasy worlds open for exploration, and technological 
and entertainment forms. Also perhaps, casino- and pub-like grottoes, 
looking out to under the waves; and varieties of sports presentations 
and activities. Contests, fairs, festivals, holidays, erections, 
revamp ings , scribblings * 

o. Communication with other life forms, and inviting them along for 

the journey into spaces high and blue. The idea of having a dolphin 
embassy, a whale tavern in the sea (growing types of algae for 
them), platforms and niches to support many sea travellers, and 
those from the sky. 



A continuously building mural made by contributions from each ^ 
visitor in all the media. It will start from some initial point (s) 
and spread as more and more visitors come, make, and go. (Thanx, xokoj 
3 The idea of "not letting an enemy rise on any level", as Maharishi 
so aptly puts it. The foreign relations applicable as: Ideologies 
can be shared as love. Using the platform as a museum, a carousel 
of multiple nationalities and displays of bifurcate merging, develop 
events which can be generally supported by nations, groups, and 
factions. In them independent rovers can sniff around, 
r. Examinations of the acoustics, the silent cave- likes, the public 

open airy ampetheaters . Electronic and other forms of communication 
running along its circuits, and extending from its structure, 
s Visions, ideas for schools, markets, subjects to be taught: seems 
likely there's to be a concentration of the space studies on board, 
so examining some of the fields briefly: exo-ecology, Jow gravity 
motion, non-terrestrial physics, neurogenetic engineering, 
t. Health, wholeness, holiness: attaining it and keeping ^^^ ^^^ f 
the newer medicinal statements have been waiting for somewhere like 
this to display themselves, and from which to fly. 
u. The idea as the project not just an end,, a Pl\^^> 

link on the roadway. What then is to come next? What first? Vhat . 
has been encouraging this? . . , 

V The extra-realist art movement, its principles and principals, 
w! Tributes to those livers of the past who've sent good vibrations 

into our present sphere. Catacombs and hillsides. 
X The exposition and superimposition of the ideas of nakedness, 
nudity, nets of reality, and masturbation. Techniques. 

V Proposal for direct access networks to stretch across the land. 

z. 'An animal's or plant's eye view of what we humans have been discussing, 
sometimes grave, sometimes humorous. 

In closing I would like to add that all flowing waters lead to the sea. Thanks 
for the initial interest. Direct correspondance to me at: Kevui Switzer, 
1534 Ford, Lincoln Park, Michigan 48146. 



■MrMt ***** 




Applications 



EM-I ASSEMBLY LANGUAGE 



Introduction 

An assembly Language program consists of a series of Lines, each contain- 
ing 0 or 1 statements. A machine instruction may not be Labeled-. In other 
words, the label field on a machine instruction must be left blank.. There are 
two kinds of labels, instruction and data labels. Labels start in column 1. 
Instruction labels are unsigned positive integers, and each must appear alone 
on a line by itself. The scope of an instruction label is its procedure. 

The pseudoinst ructions CON, ROM,, and BSS may be Labeled with a 1-8 char- 
acter data label, the first character of which is a Letter, period or under- 
score, followed by letters, digits, periods and underscores. Only 1 label per 
line is allowed. The use of the character "." followed by a number (e.g. .40) 
is recommended for compiler generated programs, since these are considered as a 
special case and handled more efficiently in compact assembly language (see 
below) . 

Each statement may contain an instruction mnemonic or pseudoinst ruction. 
These must begin in column 2 or later (not column 1) and must be followed by a 
space, tab, semicolon or LF. Everything on the Line following a semicolon is 
taken as a comment. 

All constants are decimal unless started with a zero e.g. 0177, in which 
case they are octal. In CON and ROM pseudoinstructions, floating point numbers 
are distinguished by the presence of a decimal point or an exponent (indicated 
by E or e), or both. Double precision (Long) integers are followed directly by 
an L or I. 

Also allowed as initializers in CON and ROM are strings- Strings are sur- 
rounded by double quotes and may include \xxx, where xxx is a 3-digit octal 
constant, e.g. CON "hello\012\000". Each string element initializes a single 
byte. Strings are padded at the end up to a multiple of the word size. 

Local labels are referred to as *1, *2, etc, in CON and ROM pseudoin- 
structions (to distinguish them from constants), but without the asterisk in 
branch instructions, e.g. BRF 3, not BRF *3. 

The notation Sprocname is used to mean the descriptor number for the pro- 
cedure with the specified name. 

An input file may contain many procedures. A procedure consists of zero or 
more pseudoinstructions, a PRO statement, a (possibly empty) collection of in- 
structions and pseudoinstructions and finally an END statement. The very last 
statement on the input file must be EOF. The END directly preceding the EOF 

may be omitted. 

Input to the assemble^ is in lower case, if available. Upper case is used 
in this document merely to distinguish key words from the surrounding prose. 



T1-2. Psreudb instructions 



"ZJ^'J-^i^lJ^^Z^ °^--<'^ °^ ^^'^ P""do instructions. 
<sym> = an identifier 
<arg> = <num> or <sym> 

<val> = <arg>, long constant (ending with L or I), reaL constant, strino 
constant (surrounded by double quotes), procedure number start ng 
with $) or instruction label (starting with *). ^ 

^. - zero or more of < > 

<...>+ = one or more of <. ..> 

Four pseudo instructions request globaL data: 
BSS <num> 

onhTwo?d°'sUe!"' inmalized. <nu.> ™ust be a multiple 

HOL <nuin> 

t'his'black!^^ '^"""^ ''^'^ references will refer to 

CON <val>+ 

Assemble global data words initialized with the <val> constants. 
ROM <val>+ 

Idem, but the initialized data will never be changed. 

Three pseudo instructions partition the input into procedures: 

PRO <sym>,<num1>,<num2> 

If^'V^lj'T^'^'''^' ^^^""^ procedure name. <num1> is the number 

o^t lurr^n^m^ui;, T^^sl^'' ^ ^-^^ 

END 

End of Procedure. 

EOF 

End of module. 

slpI^^^e'S^^^^ra^^on'^^^'u-n'^^^^r^ -^^-=^-n^ -e involved with 

EXD <sym> 

Export data. <s.ym> is exported out of this module. 
IMA <sym> 

IWt address. IMA allows globaL symbol <sym> to be used before it is 



defined. Note that <sym> may be defined -in the same module. 



IMC <sym> 

Similar to IMA, but used for imported single word constants. These two 
different forms are necessary, because the assembler must know how much 
storage must be allocated if <sym> is used in CON or ROM. 

FWA <sym> 

Forward address. Notify the assembler that <sym> will be defined later 
on in this module, so that it may be used before being defined. 

FWC <sym> 

Similar to FWA, but for constants. 

FWP <sym> 

Forward procedure reference. FWP allows <sym> to be used before it is 
defined. <sym> must be defined in the same module and must not be ex- 
ported. Normally, unknown procedure names are entered in the undefined 
global reference table, so that their names will be known outside this 
module. Procedure names introduced by FWP are treated differently, how- 
ever, to prevent their being exported. 



Three other pseudo instructions provide miscellaneous. features: 



LET <sym>,<arg> 

Assembly time assignment of the second operand to the first one. 

EXC <num1>,<num2> 

Two blocks of instructions preceding this one are interchanged before be- 
ing assembled. <num1> gives the number of lines of the first block. 
<num2> gives the number of lines of the second one. Blank and pure com- 
ment lines do not count. 

MES <num>,<val>* 

A special type of comment. Used by compilers to communicate with the op- 
timizer, assembler, etc. as follows: 
MES 0 - 

An error has occurred, stop assembly. 
MES 1 - 

Suppress optimization 
MES 2 - 

Use virtual memory (EM-2) 
MES 3,<num1>,<num2> - ■ 

Indicates that a Local variable is never referenced indirectly. 

<num1> is offset in bytes from LB. <num2> indicates the class of 

the variable. 
MES 4 - 

Number of source lines (for profiler). 
MES 5 - 

Floating point used, 
MES 6,<val>* - 

Comment. Used to provide comments in compact assembly language 
(see below) . 



12. ASSEMBLY LANGUAGE INSTRUCTION LIST 



For each instruction in the list the range of operand values in the assem- 
bly language IS given. These ranges are all subranges of -32768. .32767 and are 
indicated by letters: 



m: full range, i.e. -32768. .32767 
n: 0.. 32767 
x: 0.. 32766 and even 
y: 1 or (2.. 32766 and even) 
z: -52768.. 32766 and even 
p: 2.. 32766 and even 
r: 0, 1 or 2 

The letters should not be confused with the letters used in the EM-1 in- 
struction table in appendix 2. Instructions that check for undefined operands 
and underflow or overflow are indicated by (*). 

GROUP 1: LOAD 



LOC m - Load constant (i.e. push it onto the stack) 

LNC m - Load negative constant 

LCL x - Load local word x 

LOe x - Load external word x 

LOP X - Load word pointed to by x-th local 

UI y - Load auto increment y bytes (address of pointer on stack) 
LOF m - Load offsetted. (top of stack + m yield address) 
LAL X - Load address of local 
LAE X - Load address of external 

LEX n - Load lexical, (address of LB n static levels back) 

LOI y - Load indirect y bytes (address is popped from the stack) 

LOS - Load indirect (pop byte count, address; count is 1 or even) 

LDL X - Load double local (two consecutive locals are stacked) 

LDE X - Load double external (two consecutive externals are stacked) 

LDF m - Load double offsetted (top of stack + m yield address) 

GROUP 2: STORE 



STL X - Store local 
STE X - Store external 

STP X - Store into word pointed to by x-th local 

SAI y - Store auto increment y bytes (address of pointer on stack) 

STF m - Store offsetted 

STI y - Store indirect y bytes (pop address, then data) 

STS - Store indirect (pop byte count, then address, then data) 

SDL X - Store double local 

SDE X - Store double external 

SDF m - Store double offsetted 



GROUP 3: SINGLE PRECISION INTEGER ARITHMETIC 

ADD - Addition (★) 
SUB - Subtraction (*) < 
MUL - Multiplication (*) 



-o 
> 

G) 

m 
oo 



DIV - Division (★) 

MOD - ModuLo i .e. remainder (*) 

NEC - Negate (two's complement) (*) 

SHL - Shift Left (*) 

SHR - Shift right (★) 



GROUP 4: DOUBLE PRECISION ARITHMETIC (Format not defined) 



DAD - Double add (*) 

DSB - Double Subtract (*) 

DMU - Double Multiply (*) 

DDV - Double Divide (*) 

DMD - Double Modulo (*) 



GROUP 5: FLUTING POINT ARITHMETIC (Format not defined) 



FAD - Floating add (*) 

FSB - Floating subtract (*) 

FMU - Floating multiply (*) ' 

FDV - Floating divide (★) 

FIF - Floating multiply and split integer and fraction part (*) 

FEF - Split floating number in exponent and fraction part (*) 



GROUP 6: POINTER ARITHMETIC 



ADl m - Add the constant m to pointer on top of stack 

PAD - Pointer add; pop integer, then pointer, push sum as pointer 

PSB - Subtract two pointers (in same fragment) and push diff as integer 



GROUP 7: INCREMENT/DECREMENT/ZERO 



INC - Increment top of stack by 1 (*) 

INL X - Increment local (*) 

INE X - Increment external (*) 

DEC - Decrement top of stack by 1 (*) 

DEL X - Decrement local (*) 

DEE X - Decrement external (*) 

ZRL x - Zero local 

ZRE X - Zero external 



GROUP 8: CONVERT 



CID - Convert integer to double (*) 

CDI - Convert double to integer (*) 

CIF - Convert integer to floating (★) 

CFI - Convert floating to integer (*) 

CDF - Convert double to floating (*) 

CFD - Convert floating to double (*) 



GROUP 9: LOGICAL 

AND p - Boolean and on two groups of p bytes 

ANS - Boolean and; number of bytes is first popped from stack- 

lOR p - Boolean inclusive or on two groups of p bytes 

lOS - Boolean inclusive or; nr of bytes is first popped from stack 



XOR p - Boolean exclusive or on two groups of p bytes 

XOS - Boolean exclusive or; nr of bytes is first popped from stack 

COM p - Complement (one's complement of top p bytes) 

COS - Complement; first pop number of bytes from stack 

ROL - Rotate left 

ROR - Rotate right 

GROUP 10: SETS 

INN p - Bit test on p byte set (bit number on top of stack) 

INS - Bit test; first pop set size, then bit number 

SET p - Create singleton p byte set with bit n on (n is top of stack) 

SES - Create singleton set; first pop set size, then bit number 

GROUP 11: ARRAY 

LAR X - Load array element 

LAS - Load array element; first pop ptr to descriptor from stack 
SAR X - Store array element 

SAS - Store array element; first pop ptr to descriptor from stack 
AAR X - Load address of array element 

AAS - Load address; first pop pointer to descriptor from stack 
GROUP 12: COMPARE 

CNI - Compare 2 integers. Push negative, zero, positive for <, = or 

CMD - Compare 2 double integers 

CMF - Compare 2 reals 

CMU p - Compare 2 blocks of p bytes each 

CMS - Compare 2 blocks of bytes; pop byte count 

CMP - Compare 2 pointers 

TLT - True if less, i.e. iff top of stack < 0 

TLE - True if less or equal, i.e. iff top of stack <= 0 

TEQ - True if equal, i.e. iff top of stack = 0 

TNE - True if not equal, i.e. iff top of stack non zero 

TGE - True if greater or equal, i.e. iff top of stack >= Q 

TGT - True if greater, i.e. iff top of stack > 0 

GROUP 13: BRANCH 

BRF n - Branch forward unconditionally n bytes 
BRB n - Branch backward unconditionally n bytes 

BLT n - Forward branch less (pop 2 words, branch if top > second) 

BLE n - Forward branch less or equal 

BEQ n - Forward branch equal 

BNE n - Forward branch not equal- 

BGE n - Forward branch greater or equal 

BGT n - Forward branch greater 

ZLT n - Forward branch less than zero (pop 1 word, branch negative) 

ZLE n - Forward branch L^ss or equal to zero 

ZEQ n - Forward branch equal zero 

ZNE n - Forward branch not. zero 



ZGE n - 
ZGT n - 



Forward branch greater or equal zero 
Forward branch greater than zero 



GROUP 


U: 


PROCEDURE CALL 


MRK 


n 




Mark ^tsrk fn — chanap in ^1"a1*ir Hpnl'h n"f np^"f"ino 1 ^ 


MRS 






Mark stacks first pop the static Link "frofn the stack 


CAL 


n 




ral 1 nmrpHiirp fuT't'h .Hpcp pt n+^nr 

UaLL fJIULtCUUIC VMILII'UCaUl IjJLUI 11/ 


CAS 






r^l 1 tdHt ppfh * "f T n d" nnn nr*nppHi itq niimhpr "f rnm Q+aplf 

V/QUL MlUMCUL^ 1 MOL yJ\J^ ^IwwCULIIC CILIUIUCI 11 Will o U m w N 


RET 


X 




R Pi* 1 1 rn T'fiinrTTnn ppciil'h rnncTQi'Q n"f +nn y hv+pc^ 


RES 






Like RET/ but size of result on top of stack 


GROUP 


15: 


MISCELLANEOUS 


BEG 


z 




RpnTn nrnrpHiirp f pp<jpr\/P 7 hv1"PQ "fnp I nrpi 


BES 






Like BEG, except first pop z from stack 


BLM 


X 




Block move x bytes^ first pop destination addr, then source addr 


BLS 






Block move; like BLM, except first pop x, then acldresses 


CSA 






Case jump; address of jump table at top of stack 


CSB 






Table lookup jump; address of jump table at top of stack 


DUP 


p 




Duplicate top p bytes 


DUS 






Like DUP, except first pop p 


EXG 






Exchange top 2 words 


HLT 






Halt the machine ( Exit status on the stack ) 


LIN 


n 




Line number (external 0 := n) 


LKI 






Line number increment 


LOR 


r 




Load register (0=LB, 1=SP, 2=HP) 


MON 






Monitor call 


NOP 






No operation 


RCK 


X 




Range check; descriptor at (external) x; trap on error 


RCS 






Like RCK, except first pop x fro/n stack 


RTT 






Return from trap 


SIG 






Trap errors to proc nr on top of stack (^2 resets default). Static 








Link of procedure is below procedure number. Old values returned 


STR 


r 




Store register (0=LB, 1=SP, 2=HP) 


TRP 






Cgiuse trap to occur (Error number on ^tack) 



13- KERNEL INSTRUCTION SET 



Many *pf the instructions presented in the previous chapter are replace- 
ments for a small sequence of basic instructions. The basic instructions form 
less than half of the complete instruction set. Only a few basic instructions 
have operands. Most of them fetch their arguments from the stack. Very few 
basic instructions are provided to load and store objects. 

For each of the groups of instructions .the basic ones are given: 



GROUP 


1: 


LOC, 


LAE, 


LEX, 


LOS 






GROUP 


2: 


STS 












GROUP 


3: 


ADD, 


SUB, 


MUL, 


DIV, 


SHL, 


SHR 


GROUP 


4: 


DAD, 


DSB, 


DMU, 


DDV 






GROUP 


5: 


FAD, 


FSB, 


FMU, 


FDV, 


FIF, 


FEF 


GROUP 


6: 


PAD, 


PSB 










GROUP 


7: 














GROUP 


8: 


CID, 


CDI, 


CDF, 


CFD 






GROUP 


9: 


ANS, 


I OS, 


XOS, 


COS, 


ROL, 


ROR 


GROUP 


10: 


INS, 


SES 










GROUP 


11: 


AAS 












GROUP 


12: 


CMI, 


CMD, 


CMF, 


CMS, 


CMP, 


T6T, 


GROUP 


13: 


DRB, 


ZNE 










GROUP 


14: 


MRS, 


CAS, 


RES 








GROUP 


15: 


BES, 


BLS, 


CSA, 


CSB, 


DUS, 


EXG, 






RTT, 


SIG, 


STR, 


TRP 







Almost all the other instructions can be replaced in the assembly language by a 
short equivalent sequence of simpler instructions. By applying these replace- 
ments recursively a sequence of basic irsfit ructions can be found. 



+ LOI 2 + ADI y + EXG + STX 2 + LOI y 



GROUP 1: 










LNC ni 




LOC -m 






L OL X 




LAL X 


+ 


LOI 2 


lOE X 




LAE X 


+ 


LOI 2 


LOP X 




LOL X 


+ 


LOI 2 


LAI y 




:dup.2 


+ 


DUP 2 


LOF m 




API m 




LOI 2 


LAL X 




UEX 0 


+ 


:ADI x 


LOI y 




LOC y 




LOS 


:LDL X 




LAL X 


+ 


LOI 4 


LDE X 




.LAE X 


■+ 


L OI 4 


LDF m 




ADI m 


+ 


LOI 4 


GROUP -2: 










SIL X 




LAL X 


+ 


STI 2 


STE X 








STI 2 


STP X 




LOL X 


+ 


STI 2 


5A1 y 




DUP 2 




DUP 2 


STF m 




ADJ m 


+ 


STI 2 


'STI y 




LOC y 




STS 


SDL ;X 




LAL X 


•+ 


STI 4 


•SDE X 




LAE X 


+ 


STK4 


SDF m 




API m 


+ 


STI 4 



+ LOI 2 + 'API y + EXG ^I 2 +^ STI y 



GROUP 


3; 


















MOD 






DUP 4 


+ 


DIV 






MUL 




NE(3 






UQC 0 


+ 


EX6 




+ 


SUB 




GROUP 


4: 


















PHD 






PUP 8 


+ 


DDV 






DMU 




GROUP 


6: 


















ADI 


m 


= 


LOC m 


+ 


PAD 










GROUP 


7; 


















INC 






LOC 1 


+ 


ADD 










INL 


X 


= 


UOL X 


+ 


INC 




+ 


5TL 


X 


INE 


X 




LOE X 


+ 


INC 




+ 


STE 


X 


DEC 




— 


LOC 1 


+ 


SUB 










HI 


X 




LOL X 


+ 


DEC 




+ 


STL X 


DEE 


X 


= 


LOE X 


+ 


DEC 




+ 


STE 


X 


2RL 


X 


= 


LOC 0 


+ 


STL 


X 








IRE 


X 


= 


LOC 0 


+ 


STE 


X 








GROUP 


8: 


















CIF 






CIP 


+ 


CDF 










CFI 






CFD 


+ 


CDI 










GROUP 


9: 


















AND 


P 




LOC p 


+ 


ANS 










IQR 


P 




Log p 


+ 


IQS 










XOR 


P 




LOC p 


+ 


XOS 










COM 


P 




LOC p 


+ 


COS 










GROUP 


















INN 


P 




LOC p 


+ 


INS 










SET 


P 




LOC p 


+ 


SES 










GROUP 


11; 


















LAR 


y. 




LAE X 


+ 


LAS 










SAR 


X 




LAE X 


+ 


SAS 










AAR 


X 




LAE X 


+ 


AAS 










GROUP 


12; 
















CMU 


P 




LOC p 


+ 


CMS 










TIE 






TGT 


+ 


TEQ 










TGE 






TLT 


+ 


TEQ 










TNE 






TEQ 


+ 


TEQ 










GROUP 


13; 
















BRF 


n 




LOC 0 


+ 


ZEQ 


n 








BLT 


n 




CMI 


+ 


ZLT 


n 








BLE 


n 




CMI 


+ 


ZLE 


n 








BEQ 


n 




CMI 


+ 


ZEGl 


n. 








BNE 


n 




CMI 


+ 


ZNE 


a 








BGE 


a 




CMI 


+ 


ZGE 


n 








BGT 


n 




CMI 


+ 


IQJ- 


n 








ZLT 


n 




TLT 


+ 


ZNE 


1^ 








ILE 


n 




TLE 


+ 


ZNE 


n 









RET 



BEG 
BLM 
DUP 
LIN 
LNI 
RCK 



1 n = 


TEQ 


+ 


ZNE n 


'■ n = 


TGE 


+ 


ZNE n 


n = 


. TGT 


+ 


ZNE n 


14: 








n = 


LOC n 


+ 


MRS 


n ^ 


LOC n 


+ 


CAS 


P = 


LOC p 


+ 


RES 


15: 








z = 


LOC z 




BES 


P = 


LOC p 


+ 


BLS 


P = 


LOC p 


■f 


DUS 


n ^ 


LOC n 


+ 


STE 0 




INE 0 






X - 


LAe X 




RCS 



artificial. These instructions ^^e lost tike rnr^ 

struction. Then they replace the seSue^cl: "^ ' °' ^AE in- 

UEx' : LmJ : : Zl : ADIx . STUx . LOIy 

UL X + SAI y = L0[ X + DUP 2 t ^ X + LOI y 

X . y^ = x^ : z I : z I : i : i 

the '"^^'^n-lTC^^^^^ ^^ecause the si. of 

Size y is known, then Us and SAS can be reptaced by: <'""iPt<>r. If the 

•-AS = AAS + LOI y 
SAS = AAS + STI y 



APPENDIX 1- OFFICIAL EH-1 HACHINE DEFINITIOH; 

i This is an interpreter for EM-1 . It serves as the official machine 
definition. This interpreter must run on a machine which supports 32 
bit arithmetic. 

.Certain aspects of the definition are over specified. In particular: 

1. The representation of an address on the stack need not be the 
numerical value of the memory location*. 

2. The state of the stack is not defined after a trap has aborted 
an instruction in the middle. For example, it is officially un- 
defined whether the second operand of an ADD instruction has 
been popped or not if the first one is undefined (-32768). 

3. The memory layout is implementation dependent. Only the most 
basic checks are performed whenever memory is accessed. 

4. The format of the mark block is implementation dependent. 

5. The format of the procedure descriptors is implementation 
dependent . 

6. The result of the compare operators CMI etc. are -1, 0 and 1 
here, but other negative and positive values will do and they 
need not be the same each time. 

7. The shift count for SHL, SHR, ROL and ROR must be in the range 0 
to 15. The effect of a count greater than 15 or less than 0 is 
undefined. 



program em1 (tables, prog, output) ; 



label 9999; 



const 










t13 


= 3192; 


■C 2**13 




> 


t14 


= 16384; 


-C 2**14 




> 


t15 


= 32768; 


■C 2**15 




> 


t15m1 


= 32767; 
= 65536; 


■C 2**15 


-1 


> 


t16 


•C 2**16 




> 


t16m1 


= 65535; 


■C 2**16 


-1 


> 


t31m1 


= 2147483647; 


■C 2**31 


-1 


> 



maxcoTeie-= 8191 ; 
maxdata = 8T91»; 

■C mark block format 
statd = 6; 
dynd = 4; 
reta = 2; 
mrksize = 6; 



■C highest byte in code address space > 
■C highest byte in data address space > 



"C how far is static link from lb" > 

■C how far is dynamic link from lb > 

•C how far is the return address from lb > 

■C size of mark block in bytes > 



■C procedure descriptor format > 



pdargs = 0; 
pdbase = 2; 
pdsize = 4; 

dsize =4; 
rsize =4; 
<. header words 



NTEXT 
NDATA 
NPROC 
ENTRY 
NLINE 



= 1; 

= 2; 
= 3; 
= A; 
= 5; 



■C offset for the number of argument bytes > 

■C offset for the procedure base > 

-C size of procedure descriptor in bytes > 

■C size of double precision integers > 
■C size of reals > 



escape = 0; 
undef = -32768; 

■C error codes > 
ESTACK = 0; EHEAP 
=4; ESET 



■C escape to secondary opcodes > 

■C the range of integers is -32767 to +32767 > 



ECASE 
EIOVFL 
EIDIVZ 
EFUND 
EFPP 
ELAE 
EPC 



5; EARRAY 

8; EDOVFL = 9; EFOVFL 
12; EFDIVZ = 13; EIUND 



1; EILLINS = 2; EODDZ 



= 16; ECFI 
= 20; ELIN 



= 17; ECFD 
21; EM ON 



24; EMEMFLT = 25; EPTR 
28; 



= 6; ERAN6E 
= 10; EFUNFL 
= 14; EDUND 
= 18; ECDI 
= 22; ECAL 
= 26; EPROC 



= 3; 
= 7; 
= 11; 
= 15; 
= 19; 
= 23; 
= 27; 



^ > 

■C Declarations > 
^ > 

type 

bitvaL= 0..1; -C one bit > 

bitnr= 0..15; -C bits in machine words are numbered 0 to 15 > 

byte= 0..255; -C memory is an array of bytes > 

off set= ,0. .t15m1 ; -C positive integers are offsets > 

adr= 0..t16m1; -C a machine word interpreted as an address > 

word= -t15..t15m1; -C a machine word interpreted as a signed integer > 



fuLL= -t16m1 . .t16m1 ; -C intermediate results need this range > 
double=-t31m1 . .t31m1 ; -C double precision range > 
bftype= (andf,iorf ,xorf ) ; -C tells which boolean operator needed > 
if lags= (mini, short, xbit,ybit,zbit) ; 
ifset= set of iflags; 

mnem = ( NON, 



AAR, 


AAS, 


ADD, 


ADI, 


XAND, 


ANS, 


BEG, 


BEQ, 


BES, 


BGE, 


BGT, 


BLE, 


BLM, 


BLS, 


BLT, 


BNE, 


BRB, 


BRF, 


CAL, 


CAS, 


CDF, 


CDI, 


CFD, 


CFI, 


CID, 


CIF, 


CMD, 


CMF, 


CMI, 


CMP, 


CMS, 


CMU, 


COM, 


COS, 


CSA, 


CSB, 


DAD, 


DDV, 


DEC, 


DEE, 


DEL, 


XDIV, 


DMD, 


DMU, 


DSB, 


DUP, 


DUS, 


EX6, 


FAD, 


FDV, 


FEF, 


FIF, 


FMU, 


FSB, 


HLT, 


INC, 


INE, 


INL, 


INN, 


INS, 


I OR, 


I OS, 


LAB, 


LAE, 


LAI, 


LAL, 


LAR, 


LAS, 


LDE, 


LDF, 


LDL, 


LEX, 


LIN, 


LNC, 


LNI, 


LOC, 


LOE, 


LOF, 


LOI, 


LOL, 


LOP, 


LOR, 


LOS, 


LSA, 


XMOD, 


MON, 


MRK, 


MRS, 


MRX, 


MUL, 


MXS, 


NEG, 


NOP, 


NUL, 


PAD, 


PSB, 


RCK, 


RCS, 


RES, 


RET, 


ROL, 


ROR, 


RTT, 


SAI, 


SAR, 


SAS, 


SDE, 


SDF, 


SDL, 


SES, 


XSET, 


SHL, 


SHR, 


SI6, 


STE, 


STF, 


STI, 


STL, 


STP, 


STR, 


STS, 


SUB, 


TEQ, 


TGE, 


TGT, 


TLE, 


TLT, 


TNE, 


TRP, 


XOR. 


XOS, 


ZEQ, 


Z6E, 


Z6T, 


ZLE, 




ZNE, 


ZRE, 


ZRL) 





dispatch = record 

if lag: if set; 
instr: mnem; 
implicit: word 
end; 



var 

code: packed arrayCO. 
data: packed arrayCO. 
pc,lb,sp,hp,pd: adr; 
i: integer; 
s,t,k: word; 
j:offset; 
a,b:adr; 
dt,ds :double; 
rt,rs,x,y: real; 
found:boolean; 
opcode: byte; 
escaped: boolean; 
cutoff: byte; 
dispat: arrayCboolean 



.maxcodeD of byte; <. code space > 

.maxdataD of byte; -C data space > 

■C internal machine registers > 
■C integer scratch variable > 
■C scratch variables > 
■C scratch variable used as index > 
■C scratch variable used for addresses > 
-C scratch variables for double precision > 
-C scratch variables for real > 
■C scratch > 

■C holds the opcode during execution > 
•C true for escaped opcodes > 
•C c^Dcode of first call in alternate context > 
,byteD of dispatch; 



insr: mnem; -C holds the instructio.nnumber > 

normalmap: boolean; -C true except when in alternate context > 

halted: boolean; -C normally false, set to true by halt instruction > 

exitstatus :word; -C parameter of HLT > 

uerrorlb:adr; -C static link of error procedure > 

uerrorproc:adr; < number of user defined error procedure > 

header: arrayC1..8D of adr; 

tables: text; -C description of EM-1 instructions > 

prog: file of byte; <. program and initialized data > 



■C Various check routines > 
<. ^ 



■C Only the most basic checks are performed. These routines are inherently 
implementation dependent. > 

procedure trap(n:byte); forward; 

procedure oddchkadrCaradr); 

begin if (a>maxdata) or ((a>sp) and (a<hp)) then trap(EPTR) end; 

procedure chkadr(a:adr); 

begin if odd(a) then trap(EPTR); oddchkadr(a) end; 
procedure newpc (a :adr); 

begin if (a<0) or (a>pd) then trap(EPC); pc:=a end; 
procedure newspCa :adr); 

begin if (a<lb--2) or (a>=hp) or odd(a) then trap(ESTACK); sp:=a end; 

procedure newlb(a:adr); 

begin if (a>sp+2) or odd(a) then trap(ESTACK) ; lb:=a end; 
procedure newhp(a:adr); 

begin if (a<=sp) or (a>maxdata+1) or odd(a) then trap(EHEAP); hp:=a end; 
function argi (w:word) :word; 

begin if w = undef then trap(EIUND); argi .'=w end; 

function argn(w:word) :word; 

begin if w<0 then trap(EILLINS); argn:=w end; 

function argx (w: word) : word; 

begin if (w<0) or Cw>=t15) or odd(w) then trap(EILLINS); argx:=w end; 
function argp(w:word) :word; 

begin if odd(w) or (w<=0) or Cw>=t15) then trap(EILLINS); argp:=w end; 
function argy(w:word) :word; 



bes^ifii! if w-T then sir^yi^l eUe* srgys^argpCuy end; 
fumtion argzCw : wdrdO' iword'; 

b-egin^ tf dddCw)' or Cw<-'tt5)' Of Cw>=t1i5> then trapCeiLLINS); srgti-u end; 
f uneti orf &hkovf Czr:doubHe) :u&f4? 

begin if a'bsCz) >^ ttS tlcim trapCElOVFt); chkovf;=32: end; 



■C Memory access routines- > 



■C meiffw returns a machine word as a signed; integers -5-276^ <^ mem <- 
iTiemai returns a- maehin^e weird an address i 0 <- mem^a <^ 65535 
rhemb returns a single byte as a positive integer: 0' <- mernb <- 255 
store Ca/vJ stores the word or address v at maG'hn'ne sddress' a 
storebCa'^bJ stores the byte b at n<adhine address a. 

memi returns a word from" th^e instructidn spacer Q <- menri <- 65535 

Note that the procedure descriptors are part of irtstrirdtion space.- 
riextpc returns the next byte addressed by pc, incremerlting pc 

Lino changes the line number word.- 

AU routines check to make sure the address is within range. The word 
routines also check to see that the address is even. If an addressing 
error is found, a trap occurs. > 



f un ct i on itfema ( a r ad r ) : ad r ; 
var btadr/ 

begin chkadr(a); b;-dataCa+tl; mema.'-256*fy + dataCaJ end; 

f un c t i on me m w C a r ad r ) : w o rd; 
var b:adr; 

begin bJ=niemaCa); it b>=t'f5 then memw:-b-t16 else n(emw:=:b end; 

function ifiembCaiadr) rbyte; 

begin oodchkadrCa); memb;-dataCaD end; 

procedure store(a:adr; xzfuLL); 
begin chkadrCa); 

if X < 0 then x i- x+t16; -C equivalent value, but positive > 

dataCaJ 5=: x mod 256; dataCa+tJ x div 256 
end; 

procedure storebCaradr; b:byte); 
begin oddchkadrCa); dataCa3:-b end; 



function frtemiCaradr) :adr; 



va r b'Jadr; 
begin 

if odd(a> or (a>maxcode) then trapCEPTR); 
br-codeCa+U; memi:=256*b + codeCaJ 
end; 



function next pc: byte; 

begin nextpc;-codeCpc3; newpc(pc+1) end; 

procedure lino (w sword) ; 

begin if (w<0) or (w>headerCNLIN63) then trap(ELIN); store CO,w) end; 



■C Stack Manipulation Routines > 

y 



■C push puts a word or address on the stack 

popw removes a machine word from' the stack and delivers it as a word 

popa removes a machine word from the stack and delivers it as an address 

pushd pushes a double precision number on the stack 

popd removes 2 machine words and returns a double precision integer 

pushr pushes a real (floating point) number onto the stack 

popr removes 2 machine words and returns a real number 

pushx puts an object of arbitrary size on the stack 

popx removes an object of arbitrary size ^ 

> s 

r- 

procedure push Cx:ful I); 

begin newsp(sp+2); store (sp,x) end; i— > 

CjD 

oo 

function popw;word; 

begin popwr=memw(sp); newsp(sp-2) end; 
function popa:adr; 

begin popa :=mema(sp) ; newspCsp-2) end; 
procedure pushd(y:double); 

begin -C push double integer onto the stack > newspCsp+dsize) end; 



function popd .-double; 

begin -G pop double integer from the stack > newsp(sp-dsize) ; popd:=0 end; 
procedure pushr (z: real) ; 

begin -C Push a real onto the stack > newspCsp+rsize) end; 
function popr: real; 

begin -C pop real from the stack > newspCsp-rsize); popr:=0.0 end; -o 

> 

procedure pushxCsize :off set; a:adr); m 

var i: integer; 

begin 



I 



if sfj^e-'f 

else ff G^'C&lize) op" C^i'52e<=09? 

else fof ti=*1i to- ^ze di^v 2' do piJsh'([fleintfCa-2+2*Ti)')' 

end>;' 

proce'dure pc)p>c^^<ii^e'^d1?fsel:> a>Sefd'F'5^^ 

var i :triteig!e'rX 

begin 

if si2e=1i 

then- b'e"gii'n= st-drel)(:aynjenfib"!(^s.p)OV m^pCsp^Z)' eh'di 
eise tf odtli^^t2r6> d^P ^sH&<^0^' 
tlTeti^ tp-a^CidD^U-r.)' 

e-^^e^ for i'^^^ to gifze dTV 2' d& Si&f&CS'f^ite^ZMrpop^^^ 

efid> 



-C. Bfft rtfani^tjta'ttdh; ieyctfact/' ^iftV rdtai;^.')' > 

pFo-cedure stef tCvar" w:wbF'dO'; € 1* bit lleft sfriift > 
b^^e'g.trf: if a'b^s Cw)"- tl^ tfsm tfSf iiMV^^ eise vf end:^ 

pffooed'ope^ s-rig'liliCvaF' w':wo'P'd)^/ -C 1 feft F'fght. ^h'Tft wi'-th' sigri^ 6)fteff^;<5nr- > 
fer^giiirri. iif w >= (? tli'en w; ^-^ w; .dH^v/^ 2 ed^e? w- ?= (w>-l!)' diiv? t end-;; 

p^'d'cedWe rlier^^CvaPr' w<wdrdi>> < 1 b»it fieft rdlia^e' J 

b'^itrii tf w. >=■ 

then: tf w < tl^ tfi-gw ^5=*- e tse^ wt:":* ^^w^td 

ets'e iif w -^.t4 tfteri' w» 5=^ 2*^t ©lls^e* w;=^i- 2*wW-6+1 

eYidi; 

pro'cJ^d'wFg' rrtgh^Cva'p^ w'iW(JT'd''5^; -C t hit rfght p'otate- ?• 
beg>iirf: ff dddi^wj 

tjjferl'. tf tt<0i th'eri! UiM^r^)' dH'V 2 els-^e W'- J= W-' dfv ? - tl^! 

e^'t^^ ff w<© tFre'ri' wf=^^w+tf^:^ dH'V 2: ets^e' d*fv 2 

erid/ 

fiiiFTGtfdri' b'f't C&ib'itn'F7 W!.'WG'rd7:fe'iitva-£> <• feftu-m b'ft b- of tff« word! u> > 
v-ap' iiSbftrip; 

beg-ifff. for f 1 te> b rp-igphtCw)""; bniti=fordCo'dd5Cw>5- e'ridl; 

funiGtifdn bf Ctyibftype"; w1>w2iiw'dp-dO swo-rd'> < retarn* b-ddtearT- im d-f 2' wcJrds > 

vap T-ibttnr; j^iadr; 
begifn' j;?=^(D> 

for t5' down"*©; 0* dd 

ga<?« ty of ^ 
snd'f? tf b«f*a^tfi;?+E^ftCii^u2:? - ^ then- jis=*ji+1^; 
forf f tf bttCt/Wliy-i»&tt(St/g2> 5^ cy therf 



xdrf r tf bttCt,w1HbttCt/w2)' - T then j :=j>t 
end 

end> 

tf <~ tl5m1 then bf:=j: else bf:- j - t\6 

end; 

^^^^^^^^^^^^.^^^^^ . 

■C Array tndextng; 



furictton aTraycatc(c'radr) jadr> -C s'ubscptpt caicutattdn > 
\A3r j:"wdprf;; s^tzesdffset; aradp," 
begin yt= pdpw ^ rriemwCc); 

tf Cf<0)' or Gj;>-me'mwCG+2)) then- t papCEAf?RAY>; 

stze :•- fn"em.w(c+4)'; 

tf (stze<G30' OP CCs-tze>1) and' oddCstze)) then tPapCEOCD:^); 
at := j;*s-tze+popa; 
arpay<Jale:=a. 
eimd';: 



■C DoubUe^ and ReaC Artthmettc 
^..^^.^^^^^^^^^^^ 

€ Alt pduttrieS fdp d'dubLes and reacts are dummy pouttnesv since the fopmat of 
doublies and peaLs ts not defined' tn- EM'-I. 

f tin ct ton dod ad (ds,dt idoub L e ) -.doubt e ; 
be^gtn < add; tvo- doubles > dodad J-0 end> 

f un ctt on dodsb (dsy dt :'doub L e > : doub £ €^ 

begtn -C subtra'^ct two doubles: > dddsb:=0 end-; 

f urictton dodm L (ds,dt I'dotib te): double; 

begtri -C multtpLy two ddubles- > dodmU=0 end; 

f ufietton' ddddvCdsy dt :doub le) r doub 

be~gtn' -C dtvtde twd doubles > doddvr=Cr end; 

f un^ctton dddrrt'dCds^dt :doubl6) idoubLe; 

begtn -C modulo of two doubles > dcJdmdr=0 end; 

f undt ton ddf adCx,y 5 rea I )' : pea I ; 

beigtii -C add two peals > dofadr=0^0 end; 

function dof sb(X/y:reaL) : real > 

begtn -C subtract two reals > dofsbj=0'-0^ end; 

f unct ion dof mu (X/yjreaL)':f'eal; 

begtn < multiply two reals > dofmur-0.0^ end; 



function dofdv(x,y:reaL) : real; 

begin <. divide two reals > dofdv:=0.0 end; 

procedure dof i f (x,y : reaL;var intpart^f raction:reaL) ; 
begin <. dismember x*y into integer and fractional parts > 

intpart :=0.0; -C integer part of x*y > 

f raction:=0.0; -C fractional part of x*y > 
end; 

procedure dofef (x: real;var mant i ssa :rea I ;var. exponent : integer) ; 
begin -C dismember x into mantissa and exponent parts > 
. mantissa :=0.0; -C mantissa of x > 
exponent :=0; -C exponent of x > 
end; 



Trap 



procedure trap; 

■C This routine is invoked for overflow, and other run time errors. 

For non-fatal errors, trap returns to the calling routine d> 

-J. CO 

y> 

begin 

if uerrorlb=0 then ^ 
begin ^ 

writelnC ' error n:1, ' occurred without being caught'); 

goto 9999 
end; 

■C Deposit all interpreter variables that need to be saved on 

the stack. This includes normalmap, all scratch variables that can 
be in use at the moment and ( not possible in this interpreter ) 
the internal address of the interpreter where the error occurred. 
This will make it possible to execute an RTT instruction totally 
transparent to the user program. 

It can, for example, occur within an ADD instruction that both 
operands are undefined and that the result overflow^. 
Although this will generate 3 error traps it must be possible 
to ignore them all. 

For simplicity just the normalmap flag will be stacked here > ^ 

pushCordCnormalmap)); ^ ^ 

■C Now simulate the effect of an MRS instruction > * [~ 

push(uerrorlb); -C push static link > 

pushClb); -C push dynamic link > ^ 

push(pc); < push return address > 

push(n); -C push error number > 

■C Now simulate the effect of a CAS instruction > 
newlb(sp) ; newpcCmemi (pd+pdsi2e*uerrorproc+pdbase) ); 
if n in CESTACK,EHEAP,ElLLINS,EODDZ,ECASE,ECAL,EMEMFLT,EPTR, 
EPROC,EPC: 
then goto 9999; 

end; 

procedure dortt; 
var s:adr; 
begin 

newpc(mema(lb-reta)); s :=lb-mrksize-2; newlb(mema(lb~dynd)); newsp(s); 
•C So far this was a plain ret 0 > 
normalmap := popw =1; 
•end; 
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■C Initialization and debugging >. 



procedure initialize; -C start the ball rolling >. 
■C This is not part of the official machine definition > 
const tab = ' '; 
var brboolean; 

cset:set of char; 

f:ifset; 

nmini,mbase,nshort,sbase,obase,i,j ,n:integer; 

c:char; 

function r^adword :word; 
var b1,b2:byte; a:adr; 
begin read(prog,b1 ,b2); a 
if a>=t15 then readword 
end; 

function readdouble :double; 
var a,b:adr; 

begin a:=readword; b:=readword; 

■C construct double out of a and b > readdouble :=0 

end; 

function readreal : real; 
var brbyte; i:integer; 

s larrayd . .1001] of char; 
begin i:=0; 
repeat 

read(prog,b) ; i:=i+1; sCiD:=chr(b) 

until b=0; 

if odd(i) then read(prog,b); -C skip padding byte > 
•C construct real out of character string s > readreal :=0.0 
end; 



:=b2; a:=b1+256*a; 
:=a-t16 else readword :=a 



begin 

normalmap:=true; 
halted :=false; 
exitstatus :=-1 ; 
uerrorlb:=0; 
uerrorproc :=0; 



■C initialize tables > 
for i:=0 to maxcode do codeCi3:=0; 
for i :=0 to maxdata do dataCiIl:=0; 
for b:=false to true do 
for i.:=0 to 255 do 
with dispatCb3Ci3 do 

begin instr:=NON; i f lag : = CzbitI] end; 



■C read instruction table file, see appendix 2 > 
reset (tables); insr:=NON^ 

repeat readln(tables) until eoln(tables); -C skip until empty line > 

repeat readln(tables) until eoln(tables); -C skip until empty line > 



-read In (tables); -C skip empty line > 

repeat 

insr:=succ(insr); cset:=G; f:=n; 
read(tables,c,c,c,c) ; 

while (c=' ') or (c=tab) do read(tables,c); 

repeat 

cset :=cset+CcI] ; 

read(tables,c) 
until (c=' ') or (c=tab); 

readln(tables,nmini ,mbase,nshort,sbase,Dbase); 
if 'x' in cset then f:=f+Cxbit3; 
if 'y' in cset then f:=f+Cybit3; 
if 'z' in cset then 

with di spates' in csetD CobaseD do 

begin if lag :=f+CzbitD; instr:=ihsr end 

else 
begin 

with dispatC'l' in csetDCobaseD do 
begin iflag:=f; instr:=insr end; 
for i :=0 to nshort-1 do 

with di spate's' in csetD Csbase+iD do 

begin if lag :=f+CshortD; instr:=insr; impli cit :=256*i end 
if insr=CAL then cutoff :=mbase else 
for i :=0 to nmini-1 do 

with dispatCf alseDCmbase+iD do 

begin if lag :=f+CminiIl; instr:=insr; 

implicit :=i+ord Co' ih cset) 
end; 

end; 

until eoln(tables); 

< read in program text, data and procedure descriptors > 
reset (prog) ; 

for i :=1 to 8 do n:=readword; -C skip first header > 

for i:=1 to 8 do headerCi3 :=readword; -C read second header > 

lb:=0; hp:=maxdata+1 ; sp:=0; lino(O); 

■C read program text > 

for i:=1 to headerCNTEXTH do readCprog, codeCi-ID); 

■C read data blocks > 

for i:=2 to readword do push(undef); -C ABS block > 
for i :=2 to headerCNDATAD do 
begin n:=readword; 
if n>=0 then 

for 3 :=1 to n do push(undef) 
else 

begin j:=(n+t15) div t13; n:=(n+t15) mod t13; 
case j of 
0, -C words > 
1 : -C pointers > 

for j :=1 to n do push ( readword) ; 
2: -C double integers > 

for j :=1 to n do pushd (readdouble); 
3: -C reals as character strings > 

for j :=1 to 0 do pushr (readreal) ; 

end 



end 

end; 

-C read descriptor table > 
pd:=header,DNT;EXTD; 

for i:=1 to headerINPKC>CD*pdsi2.e do read!(p^^og,•codeDpd+T-1 J); 

<: call the entry point routi;ne > 

■pushCmaxdata!).; C illegal static link > 

pushCmaxdata); £ illegal dynamic link > 

pushCmaxcode); I ilLegal return address > 

newlbCsp+Z); 

newpcCmemiCpd + pdsi;&e*:headerIENTRyD + pdbase)),; 
end; 



,C ~™ y 

a WAIN LOOP OF TiHJE liNTERiPfiETER > 

•C It should be noted that the ijitNerpreter Cmicroprpgram) for an fMH 
iinachi:ne can be written iin tiHQ fundamentally different ways.: (1) the 

instruction operands are fetched in the main loop, pr (2) the in- _^ 

stru.ction operands are fetched after th.e 256 way branch, by the exa- :i=» 

c'Ution rvoutines themselves, In this int;erpr.eter, method (ID is used ^ 

to simplify the description of execution routines., The\di spat.ch ^ 
table dispat is used to determine how the .operand is .encoded- There 

are 4 possibilities.: ^ 

=s: 

0. There is no operand ^ 

1. The operand and instruction are together in 1 byte Cmini) ^ 

2. The operand is one byt-e lf)ng and follows the -opc^ode byteCs) ho 

3. The 'Operand is twp ibyt.es l©ng and follows the opcode byte(s) ^ 

In this interpreter, the .main loop determines the operand type, 
fetches it, and leaves it in the global variable. k for the execution 
routines to iUse, Cons e,que rat ly, instructi.ons auph as LU~j> iwhich use 
three different formats, need .only be described lonce in the body of 
the interpreter.. 

Mowever, for a production interpreter, pr a hardware ;EM-ll 
machiae, it is probably better to use jnethod iZ)^ i..e. to let the 
execution routines themselves fetch their own operands^ The reason 
for this is that each .opcode uniquely determines the operand format, 
so no table lookup in the dispatcih table is needed. irbe whole table 
is not (n.eeded. Method i(2) therfifi)re executes much faster, 

However, separate .execution noutines will be needed for LOL with ^ 
a vone byte offset, and LjOL with a two byte offset. It is to avoid .r— 
this additional clutter that method (1) is ;us.ed here, in a produc- ^ 
tion interpreter, it is envisioned that the 'main loop will fet.ch the 
nexr instruction byte, and use it as an index into a 256 .word table oo 
to find the address (of the interpreter mutine to jymp t-o^ The ^ 
routine jumped to will begin by fetching its pperand, if any^ 
without any table lookup, since it kn.o,ws whi;ch forjnat to expect* 
After doing the work, it returns to the main lopp by jiUmpang in'- 
directly to a register that .contains the address of the main loop- 
When the alternate .context is entered (after the MRX lor 'M)tS in- 
structions), this register is reloaded so that an altern.ate main 
loop is used, with an aLternate branch table. A slight variation .on ' 
this idea is to have the register contain the address of the branch 
taible, rather than the address of the main lo.op^ 

Another issue is ;Whether the execution routines f;or LOL -0, LOL 
2, LOL -4, etc. should all have distinct exeputipn routines,. Doing 
so provides for the maxi.m.um speed, since the 'operand is impl-icit in 
the routine itself ^ The disadvantage is that many iraearly identi'Cal 
execution routines .will then be needed, .Another :way pf doing it is 
to keep the instruction byte fetched from memory CL.OL 0, L'OL 2, iOL 
4, etc.) in some register, and have all the lOL ;mini fprm.at instruc- -r 
tions branch .t:o a common routine.. This ro.utine .can then determine % 
the operand by subtracting the code for LOL P from the register, ^ 
leaving the true operand ;^n the register (as a jword quantity pf v- 
cipurse^. This .method makes the interpreter «m^aller, but is a bit ^ 
s Lower, 



To make this inportant point a Little cLe3rer, consider how a 
production interpreter for the PDP-11 might appear- Let us assume the 
following ^opcodes have been assigned: 

30: LOL 0 

31: LOL 2 (2 bytes, i.e. next word) 

32: LOL 4 

33: LOL 6 

34: LOL b (format with a one byte offset) 

35: LOL w (format with a one word, 'i,e. two byte offset) 



Further assume that each of the 6 opcodes will have its own execution 
routine, i.e. we are making a tradeoff in favor of fast execution and 
a slightly larger interpreter. 

Register r5 is the erol program counter. 

Register r4 is the emi LB register 

Register r3 is the em1. SP register (the stack grows toward high core) 
Register r2 contains the interpreter address of the main Loop 

The main loop Looks like this: 

movb (r5)+,r0 /fetch the opcode into rO and increment r5 

asL rO /shift rO Left 1 bit. Now: -256<=r0<=+254 

jmp *tabLe(rO) /jump to execution routine 

ftotice that no operand fetching has been done. The execution routines for 
the 6 sample instructions given above might be as foLLows: 



loLO: 


mov (r4),(sp)+ 


/push local 0 onto stack 




jmp (r2) 


/go back to main loop 


Lol2: 


mov 2(r4),(sp)+ 


/push local 2 onto stack 




jmp (r2) 


/go back to main loop 


loU: 


mov 4(r4),<sp)+ 


/push local 4 onto stack 




jmp (r2) 


/go back to main Loop 


LoL6: 


mov 6(r4),(s,p)+ 


/push locaL. 6 onto stack 




jmp (r2) 


/go back to main Loop 


LoLb: 


clr rO 


/prepare to fetch the 1 byte .operand 




bisb (r5)+,r0 


/operand is now in rO 




asL rO 


/rO is now offset from LB in bytes, not Mords 




add r4,r0 


/rO is now address of the needed local 




mov (rO),(sp)+ 


/push the local onto the stack 




jmp (r2) 




loLw: 


clr rO 


/prepare to fetch the 2 byte operand 




bisb (r5)+,rO 


/fetch high order byte first 1,!! 




swab rO 


/insert high order byte in place 




bisb (r5)+,r0 


/insert Low order byte in place 




asL rO 


/convert offset to bytes, from words 




add r4,rO 


/rO is now address of needed LocaL 




mov (rO),(sp)+ 


/stack the LocaL 




jmp (r2) 


/done 



The important thing to notice is where and how the operand fetch occurred: 
loLO, Lol2, lol4, and Lol6, (the jnini's) have ijiipLicit operands 
loLb knew it had to -^tch one byte, and did so without any table Lookup 
LoLw knew it had to fetch a word, and did so, high order byte first > 



■C- 
■C 

•c- 



Nain Loop 



■> 
> 



begin initialize; 
repeat 

opcode := nextpc; -C fetch the first byte of the instruction > 

if normaLmap or (opcode<cutoff) then 
begi n escaped :=opcode=escape; 

if escaped then opcode := nextpc; 
with dispatCescapedD Copcodej do 
begin insr:=instr; 

if not (zbit in if lag) then 
begin 

if mini in iflag then k:=impLicit else 
if short in iflag then k:=implicit+nextpc else 
begin k:=nextpc; if k>=128 then k:=k-256; 
k:=256*k + nextpc 

end; 

if xbit in if Lag then k:=k*2 else 
if ybit in iflag then 

if k=0 then k:=1 else k:=k*2 

end 

end 

end 
else 

begin insr:=CAL; k:=opcode-cutoff end; 



^ > 

-C Routines for the individual instructions > 

case insr of 

NON: trap(EILLlNS); 

■C LOAD GROUP > 

LOC: push(k); 

LNC: push(-k); 

LOL; push(memw(lb+argx(k))) ; 

LOE; push(memw(argx(k))); 

L OP: push (memw (mema ( Ib+a rgx (k) ) ) ) ; 

LAI: begin k:=argy(k); a:=popa; b:=mejna(a); store Ca,b+k); pushx(k,b) end; 

LOF: push (memw (popa+k)); 

LAL: push (Ib+a rgx (k)); 

LAE: push(argx(k)); 

LEX: begin a:=lb; for j:=1 to argn(k) do a:= roema(a-statd); push(a) end; 

LOI : pushx (argy (k) ,popa) ; 

LOS: begin k:=popa; pushx(argy(k),popa) end; 

LDL: begin ki=argx(k); p^sh Craemw(lb+k) ); push (memw ( lb+k+2)) end; 

LDE: begin k:=argx(k); push(memw(k)); push(raemw(k+2)) end; 

LDP: begin a:-popa; push (memw (a+k)); push(memw(a+k+2)) end; 



< STORE GROUP > ^ 

STL: store(Lb+argx(k),popw); 

STE: stoce(argx(k),popw); 

STP : store Cmema ( Lb+argx Ck) ) ^popw) ; 

SAI: begin k:=argy(k); a:=popa; b:=mema(a); store(a,b+k); popx(k,b) end; 

STF: begin s:=popa; store(a+k,popw) end; 

STI: popxCargyCk) ,popa); 

STS: begin k:=popa; popx(argy(k),popa) end; 

SDL: begin k:=argx(k); store (Lb+k+2,popw); store (Lb+k,popw)s end; 

SOE: begin k:=argx(k); store (k+2,popw); st6re(k,popw) end; 

SDF: begin a:=popa; store (a+2+k,popw) ; store (a+k,popw) end; 



< SINGLE PRECISION ARITHMETIC > 

ADD: begin t :=argi (popw); s:= argi(popw); pushCchkovf (s+t)) end; 
SUB: begin t :=argi (popw); s:= argi(popw); pushCchkovf (s-t) ) end; 
HUL: begin t :=argi (popw) ; s:= argi(popw); push(chkovf (s*t)) end; 
XDIV: begin t:= argi(popw); s:= argi(popw); 

if t=0 then trap(EIDIVZ) else pushCs div t) 

end; 

XMOD: begin t:= argi(popw); s :=argi (popw) ; 

if t=0 then trapCEIDIVZ) else pushCs - (s div t)*t) 

end; 

NEG: begin t :=argi (popw) ; push(-t) end; 
SHL: begin t :=argi (popw) ; s :=argi (popw) ; 

for i := 1 to t do sleft(s); push(s) 
end; 

SHR: begin t :=argi (popw); s :=argi (popw); 

for i := 1 to t do sright(s); pushCs) 
end; 



■C DOUBLE PRECISION ARITHMETIC > 

DAD: begin .dt:=popd; ds:=popd; pushdCdodadCds,dt) ) end; 

DSB: begin dt:=popd; ds:=popd; pushdCdodsb(ds,dt)) end; 

DMU: begin dt:=popd; ds:=popd; pushdCdodmd(ds,dt)) end; 

DDV: begin dt:=popd; ds:=popd; pushd (doddv(ds,dt) ) end; 

DMD: begin dt:=popd; ds:=popd; pu.shdCdodmdCds^dt)) end; 



■C FLOATING POINT ARITHMETIC > 

FAD: begin rt:=popr; rs:=popr; pushrCdof adCrs^rt)) end; 

FSB: begin rt:=popr; rs:=popr; pushr(dofsb(rs, rt)) end; . 

FMU: begin rt:=popr; rs:=popr; pushr (dof mu(rs,rt) ) end; 

FDV: begin rt:=popr; rs:=popr; pushr (dofdv(rs,rt)) end; 

FIF: begin rt:=popr; rs:=popr; dof if (rt,rs,x,y) ; pushrCy); pushrCx) end; 

FEF: begin rt:=popr; dof ef (rt,x,i ); pushr (x); pushCi) end; 



■C POINTER ARITHMETIC > 
ADI: push(popa+k) ; 

PAD: begin t:=popw; push(popa+t) end; 

PSB: begin a:=popa; b:=popa; pushCchkovf Cb-a)) end; 



< INCREMENT/DECREMENT/ZERO > 
INC: pushCchkovf (argi (popw)+1)); 

^Mc'' ^^S^" , •^ = =3''9x(k); t:=argi(meniw(Lb+k)); store(Lb+k chkovfCt+1)^ .nH- 
DEL: begin k:=argxCk); t :=argi CmemwC Lb+k) ); storeCLb+k chkovfCt-D) phH- 
ZRE: storeCargx(k),0); 



-C CONVERT GROUP > 
CID: pushdCpopw); 

t:Z,tl-7,T' " ^""^""^ end; 

CFI: begin rt:=popr; 

endj "'"^ 5m1 -0.5 then trap(ECFI) else push(round(rt)) 
rcV u*^^" dt:=popd; pushr(dt) end; 

1us"hd(-TZ5';riJ f ^^-^ > then trapCECFD) ; 

end; 



•C LOGICAL GROUP > 
XAND,ANS: 

begin if insr=ANS then k:=popw; k:=argpCk); 

for J := 1 to k div 2 do 
end;^^^'" ^•=Popw; a:=sp-k+2; storeCa,bf Candf ,«eniwCa),t)) end; 
IOR,IOS:' 

begin if insr=IOS then k:=popw; k:=argpCk)- 

for j := 1 to k div 2 do 
end;^'^'" t:=popw; a:=sp-k+2; store Ca,bfCiorf,me«wCa),t)) end; 
XOR,XOS:' 

begin if insr=XOS then k:=popw; k:=argpCk)- 

for j:= 1 to k div 2 do 
end;^^^^" t:=Popw; a:=sp-k+2; storeCa^bf Cxorf ,memwCa),t)) end; 
C0M,COS:' 

begin if insr=COS then k:=popw; k:=argpCk)- 

for J := 1 to k div 2 do 
end-^^^^'" ^*°''^^^P"*^"^^*J' bfCxorf,memwCsp-k"^2*j), -1)) end 

R^- h!n^" s:=popw; for i:= 1 to t do rLeft(s); pushCs) end ^ 

ROR. begin t:=popw; s:=popw; for i 1 to t do rrightCs); pushCs) end; 



■C SET GROUP > 
1NN,INS: 

begin if insr=INS then k:=popw; k:=argpCk)- 
t:=popw; if t<0 then trap(ESET); 

i:- t mod 16; t:=^t div 16; if 2*t>=k then trap(ESET); 
s:-meinw(sp-k+2+2*t); newspCsp-k); pushCbitCi,s)); 



end; 
XSET,SES: 

begin^ if insr=SES then k:=popw; k:=argp(k); 
t:=popw; if t<0 then trap(ESET); 

i:= t njod 16; t:= t div 16; if 2*t>=k then trap(ESET) 
for j := 1 to t do push(O); 
s:=1; for j := 1 to i do rLeft(s); push(s); 
for j := 1 to k div 2-t-1 do push(O) 
end; 



-C ARRAY GROUP > 
LAR,LAS: 

begin if insr=LAS then k:=popa; k:=argx(k); 

pushxCmefnw(k+4), array caLc(k)) 
end; 
SAR,SAS: 

begin if insr=SAS then k:=popa; k:=argx(k); 

popx (memw(k+4), array caLc(k)) 
end; 
AARvAAS: 

begin if insr=AAS then k:=popa; k:=argx(k); 

pushCarraycaUCk)) 
end; 



■C COMPARE GROUP > 

CMI: begin t:=popw; s:=popw; 

if s<t then push(-1) else if s=t then push(O) else pushd) 
end; 

CMP: begin a:=popa; b:=popa; 

if b<a then push(-l) else if b=a then push(O) else pushd) 
end; 

CMD: begin dt:=popd; ds :=popd; 

if ds<dt then push(-l) else if ds=dt then push(O) else" pushd) 
end; 

CMF: begin rt:=popr; rs:=popr; 

if rs<rt then pushC-1) else if rs=rt then push(O) else pushd) 
end; 
CMU,CMS: 

begin if insr=CMS then k:=popw; k:=argp(k); 
t:= 0; j:= 0; 

white (j < k) and (t=0) do 

begin a:= memaCsp-j); b:=mem&(sp-k-j); 

if b<a then t:= -1 else if b>a then t:= 1; 
j:=j+2 
end; 

newsp(sp-2*k) ; push(t); 
end; 



TLT: 


if 


popw 


< 


0 


then 


pushd ) 


else push(O); 


TLE: 


if 


popw 


<= 


0 


then 


pushCI ) 


else push(O); 


TEQ: 


if 


popw 




0 


then 


pu^shd ) 


else push(O); 


TNE: 


if 


popw 


<> 


0 


then 


push CI ) 


else pushCO); 


TGE: 


if 


popw 


>= 


0 


then 


pushd) 


else pushCO); 



T6T: if popw > 0 then pushd) eLse pushCO); 



■C BRANCH GROUP > 

BRF: newpcCpc+argnCk)); 

BRB: newpcCpc-argnCk)); ^ 

BLT: begin t:=popw; if popw < t then newpc Cpc+argn Ck) ) end; o 

BLE: begin t:=popw; if popw <= t then newpc Cpc+argnCk) ) end; 

BEQ: begin t:=popw; if popw = t then newpc Cpc+argnCk) ) end; 

BNE: begin t:=popw; if popw <> t then newpc Cpc+argnCk) ) end; m 

B6E: begin t:=popw; if popw >= t then newpc Cpc+argnCk) ) end; g 

B6T: begin t:=popw; if popw > t then newpc Cpc+argnCk)) end; 

:tfc 

ZLT: if popw < 0 then newpcCpc+argnCk) ) 

ZLE: if popw <= 0 then newpc Cpc+argnCk) ) 

ZEQ: if popw = 0 then newpcCpc+argnCk) ) 

ZNE: if popw <> 0 then newpc Cpc+argnCk)) 

ZGE: if popw >= 0 then newpc Cpc+argnCk)) 

ZGT: if popw > 0 then newpc Cpc+argnCk)); 

•C PROCEDURE CALL GROUP > 

■C There are four ways to mark the stack. The change in static depth can 
be given as an immediate operand or the new static Link can be provided 
on the stack. Also, the instruction may switch into alternate context, 
or not. Only two of these have mnemonics, i.e. can be used by the prog- 
rammer. These mnemonics are MRK and MRS, corresponding to the immediate 
and stacked forms respectively. The decision about using alternate con- 
text is made by the assembler. The four cases are: 

MRK: immediate, normal context 

MRX: immediate, alternate context 

MRS: stacked, normal context 

MXS: stacked, alternate context 

> 

MRK,MRS,MRX,MXS: 

begin if Cinsr=MRS) or Cinsr=MXS) then k:=popw; k:=argnCk); 
a:= lb; for j := 1 to k do a:= memaCa-statd); 
pushCa); push C lb); pushCO); 
normalmap:=Cinsr=MRK) or Cinsr=MRS); 
end; 
CAL,CAS: 

begin if insr=CAS then k:=popw; k:=argnCk); 

a:=pd+pdsize*k; t:= memi Ca+pdargs); store Csp+2-t-reta,pc); 

newpc Cmemi Ca+pdbase)); newlbCsp+2-t) ; normalmap:=true; 
end; 
RET,RES: 

begin if insr=RES then k:=popw; k:=argxCk); 

newpc CmemaC lb-ret a)); a:=sp-k; b:=lb-mrksize-2; 
newlbCmemaClb-dynd)); 

for j:= 1 to k d;^v 2 do storeCb+2*j,memwCa+2*j)); 
newspCb+k) ; 
end; 



■C i>1lS.C£LLANE0US GROUP > 
B;EG,;BES: 

begin if insr=B£S then ;k:=popw; k.:=arg2Ck); 
if 'k>=0 

then for j := 1 tp k div 2 do pushCundef) 
else new5p.(sp+k); 

end; 
0LM,BLS; 

begin if insr=BLS then k:=popw; k:;=argx(k); 
t :=popa; s:=p.opa; 

for 5 := 1 to k div 2 do store(t-2+2*j,inemwts-2+2*j)) 
end; 

CSA: begin k:=popa; b:=mejni (pd+pdsl2fi*memw(k)+pdbase); 
t := popw - jnejnw(k+4); s:=-1; 

if (t>=Q) and (t<=mejnw,(k+6) ) then s :=jnemw(k+8+2*t); 
if s=-1 then s;=me;iiwCk+2); 
if s=-1 then trap(ECAS£3 else newpc (b+s) 
end; ^ 
CSS; begin k:=pop,a; b:=memi (pd+pdsi2e*mejnw(k)+pdbase); 
t:=popw; i:=1; f ound:=f alse; 
while (i<=:mejiiwCk+43) and not found do 

if t=jnBmw(k+2+4*i) then found;:=true else i:=1+1; 
if found then s:=niejnw(k+4+4*i) else s,:=memw(k+2); 
if s=-1 then trapCECASE) else newpc Cb+s); 
end; 
DUP,DUS: 

begin if insr=DLIS then :k:=popw; k:=argp(k); 

for i :=1 to k div 2 do push (memwCsp - k. + 2)); 
end ; 

EXG: begin t:=popw; •s:=popw; push(t); pushCs) end; 
HLT: begin exi tstatus:=popw; halted := true end; 
LIN: LinoCargnCk)); 
LNI: Lino(me/iiwC0)+1); 
LOR: begin i:=k; 

case i ,of 0:push(lb3; 1:push(sp); 2:pushChp) end; 
end; 

WON: ; € WON vill not be described here > 

NOP: ; 

RCK,;RCS: 

begin if Tnsr=RCS then k:=popa; k:=argx(k); 

if (memwCspXmemwCk)) or (memw(sp)>jnemw.(k+2)) then trapCERANGE) 
end ; 
RTT: dortt; 

SIG: begin a:=popa; b:=popa; push CuerrorlbD; pushCuerrorproc); 
ue rr o rproc :=a; uerror lb : =b 
end; 

SIR: begin i:=k; 

case i of D: newLb(popa); 1: newspCpopa); 2: newhp<popa) end; 
end; 

TRP: trapCpopw) ; 



end -C end of case statement > 
until halted; 



writelnC'halt with exit status: V, exi tstatus)'; 
end- 



} 
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^PURPOSE: 

This module .provides .routine's for performing standard integer } 
arithmetic .functions with extended precision. It is designed ^ 
for use on 16-bit -machines , where it effectively extends MAXINT } 
from 32767 to roughly 256 trillion •(2"48 - 1). This is > 
particularly useful in financial applications, where you can } 
store dollar amounts in tenths of a cent aad still keep track } 
of up to $256 billion. } 

} 

IMPLEMENTATION: } 
Numbers are of type UNREAL, a Pascal record containing 6 bytes } 
(0..255) and a boolean indi&ating the 5ign. The precision ' } 
can be changed by changing the global constant BYTEMAX, and } 
by changing code as noted in Uwrite. Changing Dread is more } 
difficult, but you probably never want to read a decimal } 
number larger than 15 digits anyway... } 

3 

lEXCE'PTIONS: } 
The ErrorTrap procedure is called on all exceptions, which are } 
as follows: } 
"input too long" — too many chars in input string 3- 
"input too Targe" — value of input > .2''4'8 - 1 } 
"no number found" — Uread encounters a nan-digit -'befope} 
finding a digit } 
"division by zero" } 
"addition overflow" } 
"mult overflow" } 
The values returned by a proc6dune/f unction are undefined if an } 
exception is found. } 

} 



The following operations are available: } 

} 



Unegate (a: unreal ) 

ULIadd (a,:b: unreal; VAK c: unreal) 

UUsub (a,b: unreal; VAR c: unreal) 

UUmjlt (a.b: unreal; VAR c: unreal) 

UUdiv (a.b: unreal; VAR q.rem: unreal) q 



-a } 

a + b } 

a - b } 

a * b } 

a DIV b; } 

•rem := a MOD b } 

UUgreater (a.b; unreal): boolean true iff a < b } 

UUequal (a.b: unreal): boolean true iff a » Ja } 

Uzero .(a: unreal): boolean true iff a = 0 } 

Uread (VAR f : text; VAR num: unreal) } 
reads a number in decimal iform, converts type unreal } 

Uwrite (VAR f: text; num: unreal; fieldwidth: integer) } 

converts from unreal to decimal rform, writes to fil^ } 

f, using fieldwidth specified. ,Writes all •*'s if } 

fieldwidth is too small } 

lUconvert (a: integer; VAR b: unreal.) } 
converts integer to unreal } 
Ulconvert (a: unreal; VAR b: integer): boolean } 
converts unreal to integer. The function returns .a false value } 
iff a > maxint. } 




bufmax = 16; { size of write buffer, - 1 > 

byteMax = 5; { size of byte array, - 1 } 

byte = 0..255; 
unreal = RECORD 

byt: ARRAY [0.. byteMax] OF byte; 

pos: boolean; { true if it's .non-negative :} 

END; 



realArray = ARRAY [0.. byteMax] OF integer; 
.wrnteBuf = ARRAY [C.bufmax] OF integer; 
digArray = ARRAY [D..2] OF 0..9; 
string = PACKED ARRAY •[0..19] OF char; 

procedure UUSub i(a,b: unreal; VAR c: unreal); -FORWARD; 

J 

ptrocedure 'ErrarTrap (str: string); 
BEGIN 

writeln ('*** UNREAL ARITHMETIC ERROR: str); 
write! n; 
END; 

^ „ J 

procedure Unegate (VAR a: unreal); 

BEGIN 

a. pos := NOT a. pos 
END; 

{ . ^ 

function Uzero (num: unreal;): .boolean; 

VAR i: integer; zip: boolean; 

BEGIN 

aip := TRUE; 

FOR i := 0 to byteMax DO zip :^ zip AND (num.bytCi] 5= D); {test all bytes} 
Uzero := zip 
END; 

^ ^ „j 

function UUequal .(a,j3: unreal): boolean; 

VAR i: integer; eq: boolean; 

■BEGIN 

eq := TRUE; 

FOR i := 0 to byteMax DO eq :- eq -AND .(a.byt[i] = b.bytFi]); 
IF a. pos o b.pos THEN eq := FALSE; 
{just in case both are 0, but of different sign...} 
IF Uzero(a) .AND Uzero(b) THEN eq := TRUE; 
UUequal := eq 
END; 

^ y 

procedure lUcpnvert (a: integer; VAR u-: unreal); 

VAR i: integer; 

BEGIN 

FOR i := 2 to byteMax DO u.byt[i] :» 0; 
u.byt[l] := ,ABS(a) DIV 256; 
u.bytCO] := .ABS(a) MOD 256;; 
u.pos := (a >= ,0) 
END; 

< } 

function Ulconvert (u: unreal; VAR a: integer): boolean; 

{ returns TRUE iff u is in range -32767 .. t32767 } 

VAR small : boolean; 
i: integer; 

BEGIN 

small := TRUE; 

FOR i := 2 to byteMax DO small := small AND {u.bytCi] - 0); 

Ulconvert ;= small; 

a := u.byt[l] * 256 + u.byt[0]; 

IF NOT u.pos THEN a := -a 



•} 



function UUGreater (a.b: unreal): boolean; 

VAR loc: integer; 

state: (bigger, same, smaller); 

BEGIN 

IF U2Bro(a) AND Uzero{b) THEN UUGreater := FALSE 
ELSE IF a.pos AND NOT b.pos THEN UUGreater := TRUE 
ELSE IF NOT a.pos AND b.pos THEN UUGreater := FALSE 
ELSE 

BEGIN {at this point, a and b must have same sign} 

state := same; 
iQc := byteMax; 
REPEAT 

IF a.byt[loc] > b.byt[loc] THEN state := bigger 

ELSE IF a.byt[loc] < b.byt[loc] THEN state := smaller; 

loc := loc-l; 

UNTIL (state <> same) OR (loc < 0); 

IF a.pos 

THEN UUGreater := (state = bigger) {when both are pos.} 

ELSE UUGreater := (state = smaller); {when both are neg.} 

END; 

END; 



^ 

procedure Uread (VAR f: text; VAR num: unreal); 

VAR i.strLen: integer; 
tmp: realArray; 

si: array [0..bufmax] of char; 
s: writebuf; 



BEGIN 

{initialize} . 

FOR i := 0 to bufmax DO BEGIN s[i] := 

WHILE f- = ' ' DO get(f); 
num. pos := NOT (f'^ = '-'); 



+'] THEN get(f); 



0; sl[i] := 'O' END; 

{skip leading spaces} 
{look for minus sign} 
{eat leading sign} 



IF f- IN [• 
st^Len■ := 0; 

WIIIJIE, (f^ IN ['0'..'9']) AND (strLen <= bufmax) DO 
BTi^IN 

read (f. sl[strLen]); 
StrLen := strLen + 1; 
END; 

IF StrLen > bufMax THEN ErrorTrap ('input too long 
ELSE IF StrLen = 0 THEN ErrorTrap ('input not found 
ELSE 
BEGIN 

{now reverse the string and convert from chars 
FOR i := 0 to strLen-l DO s[i] := ord(sl[strLen' 



{read into a string of digits} 



integers} 
-1]) - ordCO'); 



{abracadabra. . . 

[0] 

:4] 



tmp[0] 
tmp[l] 



tmpCZ] 

tmpC3] 
tmp [4] 
tmp[5] 



3] 
7] 

11]* 
5] 
_93 * 
s[13]* 
= sC8] * 
s[12]* 
= s[10]* 

= s[13]* 



convert the digit 
+ s[l] ♦ 10 
s[5] * 
s[4] * 
s[8] * 
s[12]* 
s[6] * 
s[10]* 
sC14]- 
s[9] * 
s[13]* 
s[ll]* 



IB • 



150 
232 



154 • 
114 • 



212 ■ 
2 ■ 
243; 

9 + s[14]* 90; 



array to 
+ sC23 * 
+ sCB] » 
+ s[3] * 
+ s[9] * 
+ S[13]* 
+ s[7] * 
+ s[ll]* 

+ s[lG]* 
+ s[l4]* 
+ sC12]* 



base 256} 
100 + s[3] 



64 
134 
202 
160 
152 
118 



SC7] 
s[6] - 
s[10]^ 
s[14]^ 
s[8] ^ 
s[12]^ 



232 + 
128; 

66 + 
228 + 

64; 
245 + 
165 + 



84 + s[ll]* 72 + 
16; 

232 + s[13]* 24 + 



FOR i := 0 to byteMax - 1 DO 
IF tmp[i] <= 255 

THEN num.bytCi] := tmp[i] 
ELSE 
BEGIN 

tmp[i+l] := tmp[i^l] + tmp[i] DIV 256; 

num.byt[i] := tmp[i] MOD 256 

END; 



{check for high byte overflow} 

IF tmp[byteMax] <= 255 

THEN num.byt[byteMax] := tmp[byteMax] 
ELSE ErrorTrap ('input too large '); 

END; 



procedure Uwrite (VAR f: text; num: unreal; fieldwidth: integer); 



VAR 



BEGIN 
FOR i 



s: writeBuf; 

i,j: integer; 

digits: digArray; 

started, goodsize: boolean; 

^ _ —J 

procedure GetDigits (num: byte; VAR digs: digArray); 
BEGIN 

digs[2] := num DIV 100; 
digs[l] := num MOD 100 DIV 10; 
digs[0] := num MOD 10 
END; 



0 to bufmax DO sfi] 



{0th byte} 

GetDigits (num.byt[0], digits); 

FOR i := 0 to 2 DO s[i] := digitsCi]; 

{1st byte -- multiply by 256, add to s} 
GetDigits (num.byt[l], digits); 
FOR i := 0 to 2 DO 
BEGIN 

sC2+i] := sC2+i] + digits[i] * 2; 
s[l^i] := s[l+i] + digitsfi] * 5; 
sCO+i] := s[0+i] + digits[i] * 6 
END; 



{2nd byte -- multiply by 65536. add to s} 

GetDigits (num.byt[2], digits); .» 
FOR i := 0 to 2 DO 
BEGIN 

s[4+i] + digits[i] * 6; 

s[3+i] + digits[i] * 5; 

s[2+i] + digits[i] * 5; 

s[l+i] + digits[i] * 3; 

s[0+i] + digits[i] * 6 



s[4+i] 
SC3-H] 
s[2+i] 
s[l+i] 
s[0+i] 
END; 



{3rd byte — multiply by 16,777,216 and add to s} 
GetDigits (num.byt[3], digits); 



BEGIN 
s[7+i] 
s[6+i] 
s[5+i] 
sC4+i] 
sC3+i] 
sC2+i] 
s[l+i] 
s[0+i] 
END; 



sC7+i] 
s[6+i] 
s[5+i] 
s[4+i] 
sC3+i] 
s[2+i] 
s[l+i] 
sCO+i] 



digits[i 
digits[i 
digits[i 
digits[i 
digits[i 
digi ts[i 
digits[i 
digi ts[i ] 



{4th byte ~ multiply by 4,294,967,296 and add to s} 
IF ium.byt[4] > 0 THEN 
Bi-.GIN 

GjtDigits (num.byt[4], digits); 



FOR 



0 to 2 DO 



BEGIN 

s[9+i] 

sC8+i] 

s[7+i] 

s[6+i] 

s[5+i] 

s[4+i] 

s[3-^i] 

s[2+i] 

s[l-H] 



s[9+i] 
s[8+i] 
s[7+i] 
"6+i] 
5 + i] 
4+i] 
3+i] 
2H] 
1+i] 



digits[i] 
digits[i] 
digits[ 
digits[ 
digits[ 
digits[ 
digits[ 
digits[ 
digits[ 



s[0+i] s[0+1] + digitsCi] • 6 
END; 

END; 



{5th byte ~ multiply by 1,099,511,627,776 (I hope) and add to s> 
IF num.byt[5] > 0 THEN 
BEGIN 

GetDigits (num. byt[5] , digits) ; 
FOR i := 0 to 2 DO 
BEGIN . 

s[12+i] + digits[i; 
;il+i3 + digits[i; 

digits[i' 
digits[i; 
digfts[i' 
+ digits[i; 
+ digitsTi' 
+ digits[i; 
+ digits[i[ 
+ digits [i; 
+ digits[i; 
+ digits[i' 
digitsCi: 



s[12+i] 
{s[ll+i] 
s[10+i] 
sC9+i3 
s[8+i" 
s[7+i' 
sC6+i= 
s[5+i" 
s[4+i; 
s[3+i' 
s[2+i' 
s[l+i= 
sCO+i" 
END; 



s[10+i] 

sC9+i] 

s[8+i' 

s[7+i; 

s[6+i' 

s[5+i: 

s[4+i' 

s[3+i' 

s[2+i' 

s[l+i' 

s[0+i' 



1; 

0;) 



5; 
1; 
It 



* 2; 

* 7; 

* 7; 
7; 



END; 



{*•* IF YOU INCREASE THE NUMBER OF BYTES BEYOND 0..5: repeat the process 
as above for all higher-order bytes, using a multiplier that's 
256 * the multiplier for the next lower byte ***} 

{now reduce all values to range 0.,9} 
FOR i := 0 to bufmax DO 
IF s[i] > 9 THEN 
BEGIN 

s[i+l] := sCi+1] + s[i] DIV 10; 

s[i] := sfi] MOD 10 

END; 

{check to see if any digits will be lost} 
goodsize := TRUE; 
FOR i := fieldwidth TO bufmax DO 
goodsize := goodsize AND (s[i]='0); 

IF NOT goodsize 

THEN FOR i := fieldwidth-1 downto 0 DO write (**') 
ELSE 
BEGIN 

IF fieldwidth > bufmax + 1 THEN {pad w/ spaces on right if needed} 
BEGIN 

write (' 'rfieldwidth - (bufmax +1)); 

fieldwidth := bufmax + 1; 

END; 

started := FALSE; 
FOR i := fieldwidth-1 downto 0 DO 
BEGIN 

IF (s[i] = 0) AND (NOT started) AND (i > 0) 
THEN IF (NOT num.pos) AND (s[i-l] > 0) 

THEN write ('-') {leading minus sign} 

ELSE write (' ') {leading space} 

ELSE 
BEGIN 

write (sCi]:l); started :« TRUE 
END; 

END; 

END; 



procedure UUadd (a, b: unreal; VAR jc: unreal); 

VAR i: integer; 

tmp: real Array; 

BEGIN 

{first, juggle the signs} 
IF a.pos AND NOT b.pos 

THEN BEGIN Unegate(b); UUSub (a.b.c) END 
ELSE IF -NOT a.pos AND b.pos 

THEN BEGIN Unegate(a); UUsub (b.a.c) tND 



ELSE IF NOT a.pos AND NOT b.pos 

THEN BEGIN Unegate(a); Unegate(b); UUadd( a, b , c) ; Unegate(c) END 
ELSE 

BEGIN {now we know both are positive} 

FOR i := 0 to .byteMax DO tmp[i} := a.bytCiJ + b.byt^i]; 
FOR i := 0 to byteMax - 1 DO 
IF tmpni] <- 255 

THEN c.byt[i] tmpCi] 
ELSE 
BEGIN 

c.byt[i] tmp[i] - 256; 
tmpCi+1] := tmp[i+l] + 1 
END; 

IF tmp[byteMax] <=• 255 

THEN c.byt[byteMax] := tmpCbyteMax] 

ELSE ErrorTrap ('addition overflow '); 
epos :~ TRUE; 
END; 

END; 



Procedure UUsub {a, b: unreal; VAR c: unreal}; 

VAR i: integer; 

tmp: real Array; 

BEGIN 

{juggle the signs} 

IF a.pos AND NOT b.pos 

THEN BEGIN Unegate(b); UUAdd(a.b,c) END 
ELSE IF NOT a.pos AND b.pos 

THEN BEGIN UnBgate(a); UUadd(a.b, c) ; Unegate(c) END 
ELSE IF NOT a.pos AND NOT b.pos 

THEN BEGIN Unegate(a); Unegate(b); UUsub(a,b , c) ; Unegate(c) END 

{now make sure a>=b} 
ELSE IF UUGreater(b,a) 

THEN BEGIN UUsub(b , a. c) ; Unegate(c) END 
ELSE 

BEGIN 

FOR i := 0 to byteMax DO tmp[i] := a.byt[i]; 
FOR i := 0 to byteMax - 1 DO 
IF tmp[i] >= b.byt[i] 

THEN c.byt[i] := tmpCi] - b.byt[i] 
ELSE 
BEGIN 

c.byt[i] := tmp[i] + 256 - b.byt[i}; 

tmp[i+l] :» tmp[i+l] - 1 

END; 

c.byt [byteMax] :« tmp[byteMax] - b.bytCbyteMax]; 
epos :» TRUE; {it better bel} 

END; 

END; 



procedure UUmult (a, b: unreal; VAR c: unreal); 

VAR i, j: integer; 

tmp: realArray; 

BEGIN 

FOR i := byteMax DOWNTO 0 DO 
BEGIN 

tmp[i] :» 0; 

FOR j := 0 to i DO tmpCi] :«tmp[i] + (a.byt[i-j3 • b.byt[j]); 
END; 

FOR i := 0 to byteMax - 1 DO 
IF tmpCi] <= 255 

THEN c.bytCi] :« tmpCi] 
ELSE 
BEGIN 

c.byt[i] := tmp[i] MOD 256; 

tmpCi+1] := tmpCi+1] + (tmp[i] DIV 256) 

END; 

IF tmp[byteMax] <= 255 

THEN c.byt[byteMax] := tmp[byteMax] 
ELSE ErrorTrap ('mult overflow '); 
epos := (a.pos AND b.pos) OR NOT (a.pos OR b.pos); 
END; 



— . 

pYodetfurB UUDiv' (w, b : uni*"^! ; VAR q ,- rem: uripeal).? 

VPiW sTiif'tCt'v i ihi^dQei^j: 
asize, bsiae: iht'dgep'; 

functiori- TdoFar (a.b: urireafT)'/:' bodleari; 

VAR i.j'.: iritegey; s'h'if'ted; UrtreaT; 
BEGIN 

asize byteMak; 

WHILE (a.bytta&izd] = o')/ ANb' (afeize- > 0). bd asize asize' - i; 
b"^STze := byteMefxi- 

WHTIIE (b.bytCbsizre]. = 0) Artb^ ('JbViz'tf >• d) btf- tisizle^ :» bsize' - IV 
If^ as ire = bsize 

THEN TodFar TRUE 

ELSE 

FdRi r :« byt'^Miax down to 1- do' shift edLbytdiQ. ;= b.bytGi-inV 

shifted. byt[0] :- 0; 

TobPrfp := UUGreater (shifted.- 

ENDV 

END; 

^•_-_-_^_____..__^...„-^.^_.__-._^._.. 

BEGIN' 

IF Uzerb(b) 

fHEN' tfrofffa^ (' Division by- zero" 
fliSE^ 

{figure dUt quotient's &■ renin's sigjis- no#r then fdroe'- a and b positive} 
q.pbS- := (-a^pd-s AND- ti.pds). dR Nd-T (a.pos dlt b.pos); 
renv'. poS' := a'. poS'; 
a".0di := fRUE;. 
b'.po'S' TrtUg; 

FOR' i' := d' to- byrteM^x' Dd q.bytti]' :•» O'^ {initial iz'e' an"! 6's~}: 

s-rtif t'Ce := 0*-; 

WHILE Nd'T^ fooFal^ (€\b)' DO' 

FOft f := byteWax DOWNtd- 1 DD b. byt'CiQ" := b.bytCi-l],;^ {sTiift lefty 

b.byfCO]. 0; 

shi'ftCt := ^hifi:G'i; + f;; 

ENb' ; 

I^OR i- :« shif tCt DdwH-YO' 0' DO 
^'EdlN' 

WHILE Ndf UUGreateV (b.a) DO 
BEGIN' 

({.bytCiJ qvbytCi]; + i; 
uUsub (a<,b,.ai>; 
ENDt- 
IF i > 0 fHEN^ 
fiEGiN 

FOt?' j := 0' to- byteMax - 1 bO' b.bytC'j], :» B.bytf j^l-]> {shift right} 
b.bytCbyteMax] :» d; 
ENDr 
END': 

reni'.byt :=*" a.byt; 
END; 

EfJb; 

^_..__.._.^„...^.._.-^....__._>..... ......y 

pro'dedure Ma>i'il"; 

VrfR a.i.f: inte'gel*; 
x.y.z.rem: Unreal; 
cr: char; 
dummy: bodleaVi;- 

BEGllN' 
REPEAT 

write' ('Enter problem in" form' n'-op-ri: ')'; 

Ur^ead' firiput, X') ; 

r e a J' Cch); 

Uread' (input',- y)-; 

CASE ch OF 

•>': IF UUgreai;erCx,yy THEN write ('greater') ELSE Wr^ite^ fnot grtr');- 



'»*: IF UUequal(x,y) THEN write ('equal') ELSE write (.'not equal'); 
'c': BEGIN- dummy := UIcorivert(x, a) ; if dummy THEM write ('conv dK'); 

write (a:10); rUconvert(a, z) END; 
•+': UUadd (x.y.z); 
'-•: UUsub (x.y.z);" 
••': UUmult (x.ysz); 
'/•: UUdiv (x.y.z.rem); 
ENb; {case} 

write ('■ ' — > •)■; 

IF ch IN ['+\'-'.**'.*7'.'G'] THEM Uwrite (dutput.z.lg); 
IF ch='/' THEN' BESIN write (' , rem »• '); Uwrite(output,rem,10)' END;- 
writelrt; 
UNTIL false;. 
END; 



BEGIN 
Main 
END. 




Articles 



AN EXTENSION TO PASCAL READ AMD V/RfTE PROCEDURES 

Davi d A . Rov/Tand 
Real-Time Softv/are Associates 
2717 Hniegass Ave.- 
Berkeliey, CaTFf. 9J^705 
ihl5) 5ifS-8 095 

Pascal READ and WRITE have several drstlnct actions. 
They convert betv/een Internal forms of data and their 
representations as character strings^, and they, direct the 
character strfngs through files.. They are also the only 
procedures in Pascal that allow an arbitrary number of 
parameters of varying types* 

Sometimes It is useful to have the properties of READ 
and WRITE separate from the file structure., For example^ 
one may ynsii to convert an Integer to a character string and 
store the string in an array. Or one may wish to take Input 
from a keyboard directly through Its Input buffer address 
rather than defining a system handler for it. 

Files in READ and WRITE are specified by being named 
first In the parameter list*. If no file name appears, an 
appropr I ate system f 1 1 e I s i mpT I ed . The ex tens ion f s to 
allow the first parameter In the list to be the name of a 
user-defined procedure. For READ It must be a procedure 
having a parameter list like (VAR CHrCIJAR). For WRITE It 
must have a parameter list like CCH:CHAR>, 

The actions are then: for READ, every time a character 
Is sought, the user procedure is called. It returns the 
character in CH. For WRITE, *the user procedure is called 
with the character pro)Vided as the parameter^ 

This extension Is very much In the spirit of Pascal, 
which elsewhere allows procedures to be passed as 
parameters. It may seem a slight convenience in standard 
Pascal, but it is an enormous aid in the mul t I -tasking 
version of Pascal v/hich v/e have created. It allov/s one the 
full flexibility and famlirarlty of READ and WRITE in the 
absence of any operating system. It might be considered for 
other real -time and process control languages. 



PASCAL INPUT/OUTPUT 



In this example characters derived from the variable 1 
by WRITE are sent to the procedure CONVERT, which stores 
them In an array, 

VAR n 
CHARS : ARRAY (.1,, 10.) OF CFIAR; g 
C, I : INTEGER; J 

r 

PROCEDURE CONVERT(CH:CHAR); ^ 
BEGIN rr 

IF C <= CMAX 5 

THEN 

BEGIN =«= 

CHARSC.C.):=CIl; 

C:=C+1;: 
END; 
END; 

BEGIN 

C:=l; I: =437; 

WRITECCONVERT, 1); 
END. 

The second example shows liovi READ can read Integers 
directly from a hardv/are Input buffer,. 

VAR % 
I, J: INTEGER; p 

PROCEDURE GETCHCVAR CH:CHAR>; ^ 
VAR oD 

RCSR ORIGIN 1775 GOB: INTEGER; 2 

RBUF ORIGIN 17756 2B : CHAR; 
BEGIN 

/*Untn a char is ready, v^ait here*-/ 
WHILE RCSR = 0 DO /^nothing*/ ; 
CH: ==RBUF; 
END; 

BEGIN 

READCGETCH^ I, J); 
END,, 
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PDP-11 PASCAL: THE SWEDISH COMPILER 



VS 

OMSI PASCAL-1 

Margaret A. Kulos 
Naval Underwater Systems Center 
ITe-ff London, Connecticut 



ABSTRACT 



This paper presents a comparison of 
Seved Torstendahl ' s Swedish Pascal 
compiler and the Oregon Minicomputer 
Software Inc. (OMSI) Pascal-1 compiler. 

•A comparison of the results of 
applying the Pascal Validation Suite 
against hoth compilers is reported. A 
discussion of the factors that need 
consideration in transporting programs 
written for one of the compilers to the 
other, hased on the results of the 
validation suite, is presented. 



INTRODUCTION 

This paper presents a comparison of two Pascal 
compilers implemented on a .PDP-11/70 running the 
RSX-11M-PLUS operating system. 

A comparison of the results of applying the Pascal 
Validation Suite against . Seved Torstendahl' s Swedish 
Compiler and the Oregon Minicomputer Software Inc. (OMS-l) 
Pascal compiler is reported. Both compilers are discussed 
in relation to the req^uirements of the draft Pascal 
standard. Specific areas where programs written for one 
compiler may not he compatihle with the other compiler are 
highlighted. Thi^ pa-per does not discuss the differences in 
the I/O handling "by the two compilers except for presenting 
the validation suite results .for testa that examine l/O as 



stated in the draft standard. 



PASCAL STANDARDIZATION 

The formal effort to produce a standard for the Pascal 
programming language hegan in 1977 when a working group was 
formed within the 3ritish Standards Institution (BSI) . In 
Octoher 1978, Pascal was listed as a International Standards 
Organiization (ISO) work item and a working draft was 
circulated as the ISO' document (1). 

The current version of the standard (the 5th working 
draft) is "being- circulated to ISO memher hodies for comment. 
In the United States, the cognizant hody is the joint ANSI 
X3J9-IEBE Pascal Standards Committee (2). 



THE PASCAL PROCESSOR VALIDATION SUITE 

The Pascal processor validation suite "by A.H.J. Sale 
and R.A. Ereak is a series of test programs written in 
Pascal that are designed to support the draft standard 
(3,4)- This suite of programs may "be used to validate a 
compiler hy presenting it with a series of programs which it 
should or should not accept. The suite also contains a 
numher of tests that explore implementation defined features 
and the q[uality of the processor. Processors that "pass" 
all the tests" are likely to "be well designed and relatively 
trou"b.le free> although they may not "be error free. 

Use of the validation suite provides an opportunity to 
measure the quality of a processor and aids implementators 
in providing a correct implementation of "standard" Pascal 
in an effort to improve the portahlity -of Pascal programs. 

The six classes of tests in the validation suite are 
conformance, deviance, implementation defined, error 
handling, q^uality, and extension- 

Conformance programs are correct standard Pascal 
programs that should compile and execute. 

Programs in the deviance class are Pascal programs that 
differ in su"btle ways from the standard. These detect 
processors that: 

(a) handle an extension of Pascal 
(h) fail to check or limit some Pascal 
feature appropriately, or 



(c) incorporate some common error. 

Implementation defined programs detail features of the 
processor that are implementation dependent. 

The programs in the error handling category test 
situations where an error should "be detected. This enahles 
documentation of uiidetected error conditions. 

Programs that explore the quality of an implementation 
are classified as cLuality tests. 

Ttie final category of tests investigates the syntax of 
extensions to the language according to the conventions 
cited in the standard. 

All test programs are laheled "with a test numher 
corresponding to the section in the standard which gives 
rise to the test .followed "by a dash and a serial numher that 
uniq.uely identifies each test written for that section. For 
example, the test numhered 6.10-3 is the third test in the 
validation suite corresponding to that section of the 
standard numhered 6.10. 



SWEDISH jOOMPILER YALIDATION REPORT 

The following is a report of results .ohtained hy 
running the Pascal Validation Suite against the Swedish 
Compiler Version 6. The details- of the test results state 
the actions demonstrated hy the compiler for a particular 
test rather than the requirements listed- in the standard. 
Examples of syntax constructs that will cause a test to fail 
are provided in the descriptions only for those tests that 
are not self-explanatory. 

Pascal Processor Identification 

Computer: DEC PDP-1 1 /TO running RSX-1 1 M-PIUS V1 BL6 

Processor; Swedish Pascal Compiler Version 6.01 



Test Conditions 

lester: M.A. Kulos 



Date: 



Septemher 1980 



Validation Suite Version: 2.2 



Conformance Tests 

Numher of tests passed: 118 
ITumher of tests failed: 17 

Details of failed tests : 



6.1.8-1 Comment is not considered to he a. token 
separator. 

PROCEDURE (^comment*) ABC; is not a legal procedure 
heading. 

6.2.2-:? Type identifier which specifies the domain 
of a pointer type is not permitted to have its defining 
occurrence anywhere in the type definition part in 
which the pointer type occurs. 

PROaRAM Name; 
TYPE 

node=real; 



•PROCEDURE X; 
TYPE^ 

p=*node; 

6. 4. 3. 3-1 Empty field-list in variant part of 
record type definition is not allowed. 

e = RECORD 

CASE married OE 

true: ( spousename: string) ; 

false: () 

END; 

6.4.»3. 5-1 Eile of pointer to integer is not 
allowed. 

TYPE 

i=integer; 
VAR 

ptr:"i; 

filex:file of ptr; 



6. 4' 5 -5-3 The end of line marker is not inserted 
at the end of a line, if not explicitly done in a 
prog ram, 

6.6.3.1- 5, 6.6.3.4-1 and 6.6.3.5-1 Procedure 
declaration is not permitted, as argument to a 
procedure. Procedures and functions may not "be passed 
to other procedures and functions as parameters. 

PROCEDURE Conforms (PROCEDURE ahc(x: integer )) ; 

Note: Yersion 4 of the Swedish compiler would process 
this statement correctly if procedure ahc . did not have 
an argument — ^which goes along with the Jensen and ¥irth 
definition of a parameter list (5). 

6.6.3-4-2 The environment of procedure parameters 
does not conform to the req[uirements stated in the 
standard. (This test did not compile because of the use 
of a procedure as an argument to a procedure.) 

6.6.5.2- 3 "TRUE" is not assigned to «BOE" if the 
file is empty when reset. 

6. 6. 5.. 4-1 UPTPAOK is not implemented hy the 
compiler . 

6.6.6.2- 3 The arithmetic function ARCTAN is not 
implemented. 

6. 6. 6. 3- 1 Transfer functions TRUNC and ROUND give 
•error... floating point nmiher top large. (This error 
is due to the failure of the function PIY on a negative 
numher rather than the impilementation of the 
functions.) 

6.8.2.4^1 ^Jon-local G-OTO statements are not 
allowed. 

6.8.3-9-7 The use of extreme values in a EQR loop 
causes wraparound (overflow), - leading to an infinite 
loop. 



EOR i:= MAXINT-10 to MAXINT DO something; 



6. 9 .2-2 Read of a character variable is not 
eq.uivalent to correctly positioning the buffer 
variable. 



6.9-4-4 Real numbers are not correctly written to 
text files due to the fact that when a real number does 
not fit the format specified, or the fraction length is 
not specified-, the number is written to the text file 
in scientific notation. 



Deviance Tests 

Number of deviations correctly detected: 63 

Number of tests showing true extensions: 1 

Number of tests not detecting erroneous deviations: 30 

Details of extensions : 

6.1. 5-6. Lower case "e" may be used-in real numbers 
(e.g. 1.602e-20). 

Details of deviations not detected: 



6.1.2-1 NIL is not implemented as a reserved word 
and may be redefined. 

6.1,7-5 and 6.9-4-12 Packed is ignored so that 
packed array of char is identical to array of char. 

6.1.7-6- and 6.1,7-7 Strings .are compatible with 
bounds other than 1 . .n, allowing deviant programs to 
execute. 

TYPE 

alpha = 'A' . . 'Z' ; 
VAR 

a1 : array[l . .4] of char; 
a2 : array, 0. .3. of char; 
a3 : ar r ay _ 2 . . 5 . of char ; 
a4 : array[l..4j of alpha; 
BEGIN 

a1 : = 'ABCD' ; 

(* the next three are not valid assignments*) 
a2:='EEGH'; 
a3:='IJKL' ; 
a4:='MN0P'; 



6.1.7-8 Compati'bility of subranges of ohar and 
packed arrays of char is not checked and the assignment 
of erroneous values is allowed. 

6.10-5 The default file output. is not implicitly 
declared and it can "be redefined. 

:6..2-.2-4 Incorrect scope aliLows programs that are 
incorrect to compile. 

(* ' red' is used in a local pi^ocedure 
hefore its .declaration. 

PROGRAM Xxx,; 
CONSIE 

red=1 ; 
PROCEDURE lyy.; 
CONST 

m=re:d 
TYPE 

colour :( yellow, green, red) ; 

6.2.2-9 A function identifier may "be assigned 
outsidie of its block. 

6..5-5 Signed constants are permitted" in contexts 
.other than CONST declarations.. 

¥riteln(+TEN); 

6.3- 6 Scope error. .constant may h^e used in its 
own declaration. 

PROGRAM Mainprogram; 
CONST 

t.en=10j 
PROCEDURE Xocalprocedure; 
CpNS^D 

ten=tenj 

6.4- il -3 Attempt to use types in their own 
definition when the type with the same identifier is 
available in an outer scope is not detected by the 
compiler. 



6^4-2.4-2 Real constants are permitted in a 
subrange declaration. (Should be limited to subrange of 
another ordinal type.) 

6.4»5»2-2 Index type should be limited to 
ordinal- types. Compiler allows real bounds* 

tes.tarray = array [1 .5- -10.1 ] of real; 

6. 4- 3 -2-5 Strings are not required to have 
subrange of integers as an index type. 

6.4-5-2 Yar parameters which are compatible but 
not identical are allowed 

PROGRAM 

TYPE 

colour = (red, pink, orange, yellow, 

green, blue) ; 
subone = red., .yellow; 
sub two = pink. .blue; 
. VAR 

colourl : subone; 
colour2 : subtwo; 
PROCBDTIRE test (VAR coll : subone) ; 



END (-^procedure*) 

BEGIN (*main program*) 

colour2 : =pink; 

test(colour2) 
END. 

(■* Colourl and colour 2 are compatible but 
not identical. The call to procedure 
test should fail in. this example. *) 

6.4.5-3 Non-identical array types allowed as var 
parameters.. 

6,4.5-4 Non-identical record types allowed as var 
parameters. 



6.4-5-5 Non-identical pointer types allowed as var 
parameters . 

6.6.2-5 Function declaration with no assignment to 
function identifier is permitted. 

6.7-2.2-9 Unary operaonr plus is allowed to other 
than numeric operands. 

(e.g.) CONST 

dot = • . ' ; 



BEG-IN 

WRITBLN(+dot),- 

6.8.2.4-2 Jumps hetween tranches of an li* 
statement are allowed. 

6.8.2.4-3 Jumps "between "branches of a CASE 
statement are allowed. 

6.8.3-9-2, 6.8.3-9-3, and 6.8.5-9-4 Assignment to 
a EOR statement control variable within the EOR loop is 
not detected hy compiler. 

6.8.3-9-9 Non-local variahle at an intermediate 
level can he used as a EOR statement control variahle. 

6.8.3-9-14 G-lohal variahle (at the program level) 
can he used as a control variahle in a EOR statement. 

6.8.3-9-19 Nested EOR statements using the same 
control variahle are not detected. 

6.9-4-9 Attempt to output integers whose field 
width parameters are zero or negative are not detected 
hy compiler. 



Error Handling Tests 



Numher of errors correctly detected: 35 
Numher of errors not detected: 31 



Details of Errors Not Detected 



6.2.1-7 Local variables are not undefined at 
beginning of statement part. 

6.4.3.3-5, 6.'4-3-3-6, 6.4-3-3-7, 6.4.3.3-8 Variant 
un-def initiori is not detected, there is no checking on 
the tag field of variant, records. 

6.4.6-4' Value of expression out of closed interval 
of destination in assignment statement is an error and 
is detected at run time with a PASRUN error 12 
(subscripting error) occurring. The program, however, 
continues to execute. 

VAR 

Answer : array[l..5] of integer; 
i : integer; 



i:=5; 

answer :=2*i; 

6.4.6-6 Array subscript compatibility is not 
checked. 

6.4- 6-7 Members of a set expression not in the 
closed interval specified by base type of assignment 
destination are not detected as errors. 

6.4.6-8 Assignment compatibility for sets passed 
as parameters is not checked. 

6.5- 4-1, 6.5-4-2 Pointer variable with undefined 
value or value NIL when de-referenced is not detected. 

6.6.2-6 Undefined function result is not detected. 

6. 6. 5. 2-1 Put operation on file when BOE is false 
is not detected. This may occur when a file is reset 
(opened for read only) and written to. 



6.. 6. 5. 2-6, 6.6.5-2-7 Changing current file 
position vhile "buffer varia"ble is an actual parameter 
to a procedure or an element of a record variable list- 
does not produce an error message. 

6. 6. 5 •3-4, 6. 6. 5 '3-5, 6. 6. 5 • 5-6 Dispose procedure 
is not implemented. 



6.6.5-5-7 Variabiles from NEW used as operand in 
assignment , statement or actual parameter pass 
undetected. 

6.6.6.2-4, 6.6.6.2-5 Negative arguments passed to 
IN or SORT are not detected. 

6.7-2.2-5 When the second operand of DIV is zero, 
AO error is detected. 

6.7-2.2-6, 6.7-2.2-7 Result of hinary integer 
operations not in range 0. .MAXINT and 0..-MAXINT are 
not flagged as errors. 

6.7- 2.2-8 MOD 25ero is not detected as an error. 

6. .8. 5 -5-5 CASE statement that does not contain a 
constant of selected value produces no "warning. 

6.8.5.9-5, 6.8.5,9-6 The use of a EOR statement 
control variable after EOR statement vithout an 
intervening assignment or, the use of a control 
variable after a loop vhich is not entered is an error 
that is not detected. 

6. 8- 5. 9-1 7 Nested EOR statements using same 
control variable are not detected as errors. 

6.9- 2-4, 6.9-2-5 Reading integers and reals from" 
file of text when the text is not a valid integer or 
real number does not produce a diagnostic. Eor 
example, the text string read as a real 'ABC1 25-456' is 
not .detected as an error. 



Implementation Defined Tests 



The implementation defined tests in the validation 
suite* demonstrated the following characteristics of the 
Swedish compiler: 

- A rewrite is permitted oh the output file. 

- Alternate comment delimiters are implemented. 

- Bq.uivalent symbols for ^, :, and :== are not allowed. 

- BcLuivalent symbol for [ J is implemented (i.e., (. .) 
is allowed) . 

- Alternate symbols for <, <=, >=, and <> are not 
available • 

- The value of MAXINT is 52767- 

-• Ordinal numbers of set elements must lie in the range 
0..65 or ' 'for characters. 

- A measure of time and space req.uirements of a program 
which is an implementation of ¥arshall's algorithm 
yields: 

space = 570 bytes (2960 bits) 

time = 1 .066 seconds 

(This is in comparison to 0.81646 seconds 
and 1 45 bytes — 6864 bits on a Burroughs 
B67OO running the B67OO Pascal compiler 
version 2.9-0.01 . ) 

- The characteristics of the floating-point arithmetic 
system are determined to be: 

24 bit mantissa. 
. Rounds on arithmetic. 

EPS (smallest positive number such that 

1 .0+BPS 0 1 .0)is: 

6.4604644E-08. 
The. smallest positive floating point 

number is: 2. 9587557B-59 - 
The largest positive floating point 

number is: 1 . 701 41 1 9B+58. 

- The value of expressions are fully evaluated before the 
boolean value is determined. ' 

- Index is selected before an expression is evaluated. 

- Expression is evaluated before a pointer is 
de-referenced. 

- The output buffer is flushed at the end of program 
execution. 

- Real numbers are written with two exponent, digits . 

- Default field width values are: 

Integer 8 characters 

Boolean 6 characters 



Real 



t5 characters. 



A total of 18 implementation defined tests -were run. 



Quality. Tests 



Twelve q[ualit.y tests were executed, producing the 
follo-wing observations: 

~ There are 10 significant characters in an identifier. 

- The compiler does not assist in detecting unclosed 
comments . 

- Kore than 50 types are alloived^ 

- More than 50 labels permitted. 

- More' than tOO variable declarations allowed. 

- Functions SQRT, EXP, SIIT, COS, are implemented 
consistently. 

- Function ARCTAN is not implemented. 

- Operator DIY does not handle negative values correctly. 

- Warnings are not generated for impossible cases in a 
CASE statement. 

- FOR statements may be nested at least 15 levels deep. 

- FOR statement control variable may be accessed upon 
exit from loop (value is last value in loop) . 

- Recursive I/O is allowed using the same file. 

- Large populated CASE statement (containing 255 
constants) is allowed- 



Extensions 



UTumber of tests run = 1 

The only extension test run demonstrated that the 
OTHERWISE clause in a CASE statement has not been 
implemented but has instead been modified to use the word 
OTHERS as. a case .constant. 



OMSI VALIDATION REPORT 



The OMSI Pascal-I compiler was tested against the 
Pascal Validation Suite by Barry Smith, a member of the 
Oregon Software implementation/maintenance team in September 
1979 (6). 



Conformance Tests 



Of the 137 conformance tests attempted, 15 failed. The 
major reasons were: 

- Comment delimeters not required for pairwise matching. 

- Pointer scope not handled correctly. 

- Assignment to function identifier within nested module 
generates faulty code.- 

- Empty record types and cases, are not allowed. 

- Eq_ual, compatible sets- of different base types do not 
compare . 

- Set of char is implemented as a 64 element set. 

- Procedural parameters do not conform to draft standard 
proposal. 

- End of file on empty temporary file not checked. 

- Pack and unpack not implemented. 

- Empty field specifications not allowed in record 
declarations. 

- Conversions on reading real numbers not identical to 
the conversions performed by the compiler. 

- Writing boolean values is incorrectly right-justif ied. 

Deviance Tests 



Forty-one of the 95 deviance tests attempted in the 
compiler test proved to be deviations to the standard. The 
basic causes were: 

- Real number constants without digits after point 
allowed. 

- Packed array of char identical to array of char 

- Req[uirements to be a string- type are not checked. 

- Empty string allowed. 

- Incorrect scope allows incorrect programs to compile 
and execute. 

- Invalid programs where function identifier is 
inaccessible. 



- Inunction identifier may be assigned outside of its 
block . 

- Packed scalars, subranges and type-identifiers are 
allowed. 

- Non-integer subrange index types are allowed for string 
types. 

- The use of a set of real is not detected. 

- Compatible but not identical var parameters are 
allowed. 

- Non-identical array types and pointer types allowed as 
var parameters. 

- Pile assignment and records containing file components 
compiled as descriptor copy- 

- Functions without assignment to function identifier 
allovred. 

- GOTO statements that transfer into structured statement 
components are allowed. 

- Control variable in a FOR statement may be from any 
level of the program and may be assigned a value within 
the statement. The same variable may also be' used in 
nested loops. 

- Use 'of external file (other than program parameters) 
not stated. 

- The files input and output are not implicitly declared 
at the program level, but at a lexically enclosing 
level. 

- The entire program heading may be omitted. 
Error tests 



Of the forty-eight tests attempted, 11 detected 
errors while 35 of the remaining tests compiled and 
executed without detecting the areas where the code 
deviates from the standard. The basic causes of 
undetected errors were: 

- Use of un-defined values. 

- Variant undef inition. 

- Assignment compatibility (except index type in arrays). 

- NIL or undefined pointer de-referencing. 

- Undefined function result. 

- Pile buffer aliasing and use of file. 

- Some disposing conditions with ujadefined values or var 
parameters . 

- Dynamic variant record . used in expression or 
assignment. 

- Succ or pred of limiting value in type. 

- Chr of very large integer. 

- Overflow of integer ^ype. 



- Assignment compatibility with overlapping sets. 

- Case expression with no matching label. 

- Use of for statement control variable after loop^ 
termination* 

- Nested loops using same control variable. 



Implementation Defined Tests 



The execution of the implementation defined tests 
showed the following results: 

- The value of MAXINT is 52767- 

- The set of char is not implemented (but is equivalent 
to the set of characters from underscore character to 
the back-arrow character. 

- Set limits are 0 to 63' 

- Standard functions are not allowed as functional 
parameters . 

- Real representation is as follows: 

24 bit mantissa. 
Rounds on arithmetic. 
EPS = 5-96E08. 

Minimum floating point number is: 

2.393E-39. 
Maximum floating point number is: 

1 .70E+38. 

- Boolean expressions are evaluated fully. 

- Index to array selected before expression evaluat.ed 
(e.g. a[i] :=exp) . ^ ^ ^ 

- Evaluation before dereferencing in the statement 
p^ :=exp. 

- Real numbers are written with two exponent digits. 

- Default field widths are: 

Integer 7 
Boolean 5 
Real 1 3 

- A rewrite is permitted on the output file. 

- Alternate symbols are allowed only for comment 
delimiters . 



Quality tests 



Twenty-seven q.uality tests were attempted, with three 
tests failing for the following reasons: 

- Could not handle program with 50 lahels (infinite 
loop) . 

- The use of a real expression in. the SIN/COS test 
generated error for lack of register. 

- Fatal error when compiling 11 nested for loops. 

The cLuality measurements resulting from the other 21 
tests demonstrate the following: 

- Identifiers of any length are allowed, disallowing all 
mis-spellings. 

- Unclosed comments take the remainder as comment with no 
warnings . 

- More than 50 types are allowed. 

- Array[ integer] is detected "but diagnostic message 
produced is not a applicable warning. 

- Record fields are allocated representation space in 
declaration order. 

- .More than 100 variable declarations are allowed. 

- Less than 10 nested procedures are allowed, 

- Mod is inconsistent for negative operands. 

- No warnings generated for impossible CASE clauses. 

- More than 256 case constants are allowed. 

- Undefined ( out-of-range) values of case expressions are 
possible but do not cause damage. 

- No more' than 3 nested ¥ITH statements permitted. 

- Textfile without EOLN at end is still printed. 

- Recursive I/O allowed on same file. 



COMPARISON OP VALIDATION TEST RESULTS 



A comparison of the results of applying the Pascal 
Validation Suite to both the Swedish compiler and the 
OMSI Compiler produced the results shown in table 1 ^ 



CirASS 


SWEDISH COMPILER 


OMSI COMPILER 


CONEORMANCE. 


87^ 


89^ 


DEVIANCE 




56^ 


BRRORHANDLING- 


76^ 


76^ 



Table 1 

Percent of Test Results 
Consistant with Draft Standard 



The results sh9W that both compilers conform 
relatively well to the standard definition in accepting 
"correct" programs. They are also comparable in error 
detection. 

The OMSI compiler appears to deviate in more cases 
than the Swedish compiler in that it accepts more 
syntax constructs that are not allowable according to 
the definitions. 

The following is a list of the areas where the two 
compilers differed in the conformance and deviance 
tests of the Pascal Validation Suite. The details for 
each instance are available in the validation reports 
for these compilers. It is important to note that 
these factors need consideration when trying to ensure 
that programs written for one compiler may be 
transported to the other. 

- The Swedish compiler allows redefinition of NIL. 

- The OMSI compiler allows a decimal point not 
followed by a digit. 



Comments are not allowed as token separators in 
the Swedish compiler. 

The Swedish compiler permits lower case "e" to Tae 
used in real numbers. 

The OMSI compiler comment delimiters do not have 
to "be a pairwise match. 

The OMSI compiler allows invalid programs with 

inaccessible function identifiers and functions 

that attempt assignments outside their blocks. 

Assignment to a function identifier from within a 

nested procedure or function generates bad code. 

The OMSI compiler allows signed characters, 

strings, scalars, and enumerated types. 

The Swedish compiler permits a constant to be used 

in its own declaration. 

Real constants are allowed in subrange 

declarations by the Swedish compiler. 

The OMSI compiler allows packed scalars, subranges 

(i.e., not restricted to structures), and packed 

type identifiers. 

The Swedish compiler allows real bounds as an 
index type. 

The Swedish compiler allows the use of undefined 
variants in a record. 

The OMSI compiler does not detect the use of a set 
of reals as erroneous. 

A file of pointer to integer is not allowed by the 
Swedish compiler. 

The Swedish compiler allows non-identical record 
types as var parameters. 

Compatability of file types and records containing 
file components is allowed by the OMSI compiler. 
Eq[ual compatible sets of different base types do 
not compare as egual in.' the OMSI compiler. 
Unpack is not supported by the Swedish compiler. 
The Swedish compiler does not support* the ARCTAW 
function. 

Non-local G-OTO statements are not allowed by the 
Swedish compiler. 

In the Swedish compiler, the assignment does not 
follow the expression evaluation in a FOR 
statement. 

The control variable in a FOR statement is allowed 
as a formal parameter by the OMSI compiler. 
Reading a character variable is not eq.uivalent to 
correctly positioning the buffer variable in the 
Swedish compiler. 

The Swedish compiler does not allow redefining the 
default file at a local level. 

Real numbers are not correctly written to text 



files by the Swedish compiler because the format 
defaults to scientific notation when' the real 
number does not fit the format specified. 

- Negative field widths give undesired output and 
issue no warning in the Swedish compiler. The- 
OMSI compiler uses the absolute value of the width 
and gives an octal interpretation of the number. 

- The OMSI compiler ignores program parameters, 
allowing the use of an external file not declared. 

- The entire program heading may be omitted and not 
detected by the OMSI compiler. 

The Swedish compiler and the OMSI compiler 
generated similar results in the validation suite tests 
for standard implementation defined features and 
QLuality. The following is a list of areas where the 
two compilers differed. The reader is- again referenced 
to the validation suite reports for the details of the 
test results for each compiler. 

- The Swedish compiler allows (. .) as a substitute 
for [ ]. 

- The OMSI compiler default output. field width for 
integers is 7 characters, whereas the Swedish 
compiler default is 8. 

- The OMSI compiler default output field width for 
boolean values is 5 characters, whereas the 
Swedish compiler default is 6. 

- The OMSI compiler default output field width for 
reals is 13 characters, whereas the Swedish 
compiler- default is 15» 

- Identifiers are significant to 10 characters in 
the Swedish compiler. The OMSI compiler* has no 
limit. 

- The OMSI compiler MOD function is inconsistently 
implemented for negative numbers. 

- The Swedish compiler DIY function is 
inconsistently implemented for negative numbers. 



ADDITIOML ]<rOTES 

In further examination of the results of the tests 
of the validation suite for the OMSI and Swedish 
Compilers, it is important to note that there are areas 
in which both compilers disagree with the proposals of 
the draft standard. These items should also be 
considered when writing programs for either compiler in 
order to attain code that is reasonably compiler 
independent. The following is a list of features found 

-o 
> 

m 



in t)oth compilers that do not agree -with the draft 
standard. 

- Empty strings are allowed. 

Packed is ignored. A packed array of char is 
identical to an array of char and similarly with 
other structures . 

- String type req.uirements are not checked. 

- I/O files can he redefined (i.e., not implicitly 
declared at the program level. 

- Pointer scope is not handled correctly. 

- A function identifier may he assigned a value 
outside of its hlock. 

- The unary operator is allowed with a constant 
identifier. 

- String types are allowed to have non-integer 
suhrange index types. 

- Empty record types with semicolons and empty case 
variants are not permitted. 

- Yar parameters that are compatihle hut not 
identical are allowed. 

- Non-identical array types and non-identical 
pointer types are allowed as var parameters - 

- A function definition with no assignment to the 
function identifier is allowed, 

- Only the procedure parameters as" defined hy Jensen 
and ¥irth are allowed. 

- End-of-file is not checked on an empty temporary 
file. 

- GOTO statements are allowed to transfer into 
structured statement components. 

- Assignment to a EOR control variahle is allowed 
within the EOR statement. 

- The EOR statement control variahle is allowed to 
he program glohal. 

- Nested loops using the same control variahle 
produces an infinite loop. 

- The Swedish compiler allows an otherwise clause in 
a case statement, using the word OTHERS as a case 
constant (the standard proposes OTHERWISE) . The 
OMSI compiler, however, allows an ELSE clause 
similar to the ELSE clause of an IE statement, 
rather than a case lahel. 



CONCLUSION 



This paper has no conclusion. The statistical 
differences comparing hoth compilers to the draft 
standard are not ahsolute measures of the "correctness" 
of a compiler and should not he viewed as such. The 
intent of this discussion has heen to present the 
differences hetween the Swedish Pascal Compiler and the 
OMSI Pascal-1 Compiler from a user perspective, 
considering what syntax construct are particular to a 
certain compiler and should not he used in programs 
that are intended to he transportahle. It would he 
difficult to say. that one compiler is hetter than the 
other hased soleiy on the information presented in this 
paper. 
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TEXT VERSION: 2. 50-01 INSTALLED AUG- 1980 
ON: MEAP 11/70 SYSTEM' 
EOR HELP CALL: 

STEPHEN P. PACHECO (4750) OR ROY E. TOZIER (4754) S 
START OE RUN: 16:0^:58 26-0CT-80 ^ 

END OE RUN 16:04:15 ELAPSED ¥ALL TIME= 30. 95 SECONDS. ^ 

COr/IMAND LINE SUPPLIED TO TEXT: S 
**TXT ©PAPER/ ~SP ^ 

********** RUN STATISTICS ^ 
922 RECORDS READ 895 RECORDS WRITTEN 25 PAGES GENERATED 

102 RECORDS USED IN TEMP FILE. 
ONE OR MORE "SAVED STATE" RECORDS REMAIN STACKED. 

MULTIPLE INPUT FILES USED: 

ahstract.txt 
intro . txt 
standard.txt 
validate.txt 
swedrpt.txt 

omsirpt.txt ^ 
compare.txt ^ 
conclude.txt r— 
ref.txt 
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Open Forum For Members 



sper^y4=univac 

P.O. Box 43942 MS-4162 

T.. 1 St. Paul, MinnesoU 55164 

Rick, 

With all this talk about Ada replacing Pascal as the avant-garde language of the eighties, I 
thought I would contribute these definitions from The Name for Your Baby, by Jane Wells and 
Cheryl Adkins [Westover Publishing Company, Richinond, Virginia. 1972]: 

ADA: (Aida, Eng.) "Prosperous, happy"; Old English 
PASCAL: Born of suffering; Hebrew 

But then again, what's in a name? 



Scott H. Costello 




MATHEMATISCHES INSTITUT D 8 MtTNCHEN 2, den 

DER l4tJDWIG-MAXIMII.TAN8-TJNIVERSITA.T TITERESIENSTRASSE 30 

MtJNCHEN DTTRCirWAHL 38 04/ 

^ „ ^ . , -r^ tVERMITTtiTCTNG a80 41) 

Prof. Dr. Gomtlier Kraus 



I am going to deTelop PASCAi - programs for use in pure mathematics 
(Complex Analytic Geometry, Algetoaic G-eometry, AlgeTDraie Topology). 
Wlio is interested to join ideas arid experiences? 
I am interested in commercial applications, too. 

Guntlier Kraus, Mathematisclies Institut der Universitat Miinclien, 
T3ieresienstraf3e 59, D-8000 Munclien 2 (West Geimany) 
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SHAI MICRO COMPUTERS LTD. 



JERUSALEM. ISRAEL, GIVAT SHAUL B*. TEL 521 1 1 1. P.O.B 3405 
CABLES: RIMCO. TELEX: 25387 



Pascal Users Group 
DEC 

5775 Peachtree 
Dunwoody Road 
Atlanta, GA 30342 



Sirs: 



Our firm has developed a Pascal based program generator called "MINIAC" 
which makes possible an 80-90% reduction in the time required to write 
typical business data processing programs. 

I enclose a brochure describing MINIAC, which we have implemented in the 
UCSD p-System, a microcomputer environment. We are planning a CP/M imple- 
mentation soon, and we forsee no special problems in implementing MINIAC 
in any environment which provides a sufficiently powerful Pascal. 

We have been using MINIAC for nine months to develop software for our 
clients in Israel, and we feel that our initial expectations were fully 
justified. 

We are planning to market MINIAC in the United States, and it is for this 
reason that we are contacting you. Perhaps MINIAC would be of interest to 
some of your members. 

If so, we would be pleased to answer any questions they may have. 
Thanking you in advance for your consideration, I remain 

Sincerely, 

Alex Ragen /I 
General Manager 



ar/hs 
enc 



southwest decision systems, inc. 

30 west bayaud, suite 2Q1 

denven, Colorado S0223 

(text of notice for Pascal News ) 

Southwest Decision Systems, Inc. is a small software 

house in Denver, Colorado, specializing in the writing 

and installation of Pascal-based software on microcomputers. 

We would welcome leads from university faculty, in the 

U.S. or elsewhere, concerning exceptional students near 

the M.S. (or equivalent) who might be suitable for 

positions with S.D.S. starting late 1982. Demonstrated 

ability to conceive and complete a substantial Pascal 

programming project to a very high standard will be the 

principal requisite. Replies (from faculty only , 

please) to David P. Babcock, Southwest Decision Systems, Inc., 

30 West Bayaud Avenue, Suite 201, Denver, Colorado 80223. 



Comment on A. II. J. Sale's Proposal to Extend Pascal 



by Tom Pittman 

P.O. Box 6539 

San Jose: CA 95150 



ref: SI6PLAN 16:4 p98-103 

It seems to me that while the while -statement and the repeat -statement are 
"similar" when considered through the flow chart paradigm', they actually have 
significant differences, resulting (for example) in the fact that dominator 
analysis requires only one pass if the only loop structure is repeat , but as 
many passes as the deepest nesting of loops if whfle -loops are used. 

The point is that the repeat- statement performs a valuable service in clearly 
representing a loop structure that is to be performed one or more times and 
terminated on a condition generated by the execution of the body of the loop. 
It is significant that Mr. Sale proposes to filter existing programs by 
replacing the simple repeat- statement with either a duplication of the body 
(offering opportunities to have differing versions of the code intended to be 
the same) or the introduction of that dreaded goto . The repeat- statement 
cannot be correctly simplified. 

Now; I will grant that the repeat- statement may be easily misunderstood. The 
goto- statement which is offered to replace it is surely no less misunderstood! 
Merely the fact that neither hr. Sale's students nor the poor anonynous 
programmer whose code he set up for us to ridicule are able to grasp the 
proper distinction between repeat and while , is a poor excuse indeed for the 
removal of that function from the language. The problem in understanding that 
gives rise both to the ill-conceived scanner and tiie terminal I/O excerpt is 
one of not fully thinking through the program flow', and such a fault will 
result in incorrect code whether or not the repeat -statement is available to 
be the butt of misdirected ridicule. 




COMPUTACIONES INFOTEC S.R.L. 

APARTAPO 61 1 25, CARACAS 1 060A,VENEZUELA 



AV. FRANCIISeO DE MIRANDA, GALER IAS MIRANDA, 3? PISO, CHACAO 
TELF.: (02) 333590 TLX: 23327 CENINVE 



..r. .ic!; "hoW, 
i^cscaL Lstr's S.roup, 
P.O. '.0;( C0j524, 
.'.t Let it-., f^eorjici 3033:;, 



i-bor :.r. nick Siiou: 

I recjved the ALL-P'jr;?OSE COUPOi' and I an ve-ry interested in joinino the 
,;roup. I ai. a Go-fti/i;re En-itineer cind our Company IjiFOTEC is representing i.iicro- 
con:put-2r eqiii pfi-.ont inVenezuc-La Like ALTOS, TVI, AfiADEX, f-ICROPRO, etc. ALL 
our oofti.'cre is deve Loped in PASCAL 0.:CSD, PASCAL/:., PASCAL/;:T+).. Our compu- 
ters our 2-GC ossed- 

I v/iLL subr.iit in the future sor:e ideas or articLes concerning our expe- 
.ricnce in PASCAL. ',.'e have deveLoped a Genera L Purpose Data Base Management 
Systci.-. Generator- It is HierarchicaL and it is onLy necesary to generate 
th2 ochena c".nd aLL the rest of the syster:. wi LL viork. It incLudes a Data Mase 
Editor for data entry, viewinfj and editing, GeneraL purpose query syster. used 
to produce sub-sets of the whoLe data oase, tsbLes of information, reports, 
etc. Tha tabLes can de ncnipuLateJ with cur TabLe Systen for merging, sorting, 
joinin'j, and statisticaL anaLisis can be carried out with our Stat Package. 
For the Sche.'.ia generation there are severaL progrer.is: Scher;;a editor. List, CRT 
inc ;*rinter forniat editor, etc. 

The system was first dcveLcpea in UCSO PASCAL but has been transfered to 
PASCAL/nT+ running on CP/.r V2.xx, flP/M V1.xx, ect- It is no\: a coR:pLete menu 
driven systs;«. 

As to the .uonijership you uiLL find cncLosed a check for USD 25,00 for a 3 
year subscription, PLease hurry n'.e the .issues. 

Si ncerl^^y|aLu::^, 



l.'i LLiam I«Lenen 
Pre si dent \ 

Coinputa Clones liiFOTEC, S.R.L. 



Pascal Users' Group, c/o Rick Shaw 
Digital Equipment Corporation 
5775 Peachtree Dunwoody Road 
Atlanta, GA, 303^2 



Dear Mr.. Shaw, 

For users of interactive systems a very simple 
modification of the program, Referencer, by Arthur Sale 
adds a very useful feature. This feature causes all 
declaration parts to he printed out and thus provides a 
very handy reference document when developing large 
programs . 

The modification inserts the following: 

After line 0785 printflag:=false j 

After line 0897 printf laf » =f alse j 

Line 6 09 remove 
Line 610 remove 

Sincerely yours,.. , . ^ — 

Edkar S . Qilchrist 

218 Via Ithaca 

Newport Beach, CA, 92663 

Note: My system is AppleII+ and UCSD Pascal. 



TRS--SO UCSD PASCAL by FMG 



I would be interested in coY^respondin^ with anyone who is 
currently usinsf the UCSD PASCAL packs^e modified for the 
TRS~80 by FMG Corporation ♦ I have been usin^ the system for 
personal projects for over a year and am very satisfied with 
its oapabilitiesy except for one "problem which I hope some- 
one else has encountered and solved!!! Pro«{rams which util- 
ize random access files (usin£{ GET and PUT) appear to ran- 
domly destroy blocks on the diskette in the write mode 
(usinsf PUT)* It seems that a bu^ in the code permits (ran- 
dom) overwrite of some of the diskette sector control infor- 
mation y so that the sector is no longer able to be found* 
If anyone else has experienced this problem^ please sfet in 
touch (especially) if you have fixed it* If a P~code disas- 
sembler is available for this UCSD PASCALy I would be very 
interested in sJettin^ a hold of it* 



Richard J* Bonneau 
6 Tansilewood Drive 
Shrewsbury? MA 01545 



(617) 845-1432 



Pascal standard: Progress Report 

by Jim Miner (1981-07-31) 



The second ISO Draft Proposal for Pascal (as printed in Pascal News #20) 
has received strong support in the official vote this spring. The number of 
countries disapproving has dropped from four to one. 





Second DP 7185 




Approving 


Approvinq 


with comments Disapproving 


Italy 


Australia Japan 


Netherl ands 


Austria 


Poland * 


Canada 


Switzerland 


Czechoslovakia * 


United Kingdom 


Finland 


France 




Germany 




United States 


* country is an 


'0' member — vote is advisory. 



Some degree of compromise has been reached in the "conformant array parameter" 
issue (see Pascal News #19, page 74). Because of the convergence of support 
evidenced by this vote, it is likely that SC5 (the ISO Programming Languages 
committee) will approve the DP with a few changes at its October meeting in 
London, Once it has done so, the draft will be a Draft International Standard 
(DIS) to be voted on by a broader constituency. In short, nearly all of the 
technical work has been done on the standard, freeing it to progress through 
the remaining steps toward official adoption. The changes made to the DP will 
result from the comments submitted by the member bodies with their votes. 
Tony Addyman and Working Group 4 are presently developing those changes. 

The official comments on the DP are quite voluminous, but we have decided to 
print them here. One reason is that you can get some idea of the amount of 
effort that goes into each new draft. Remember that these comments are just 
the output of national committees, and that these committees worked hard to 
formulate the comments and to reject others. The work done by Tony Addyman at 
each stage has been tremendous. 

Another reason for printing the comments is so you can appreciate the 
difficulty of some of the technical issues,. and the tensions created by 
conflicting goals of eliminating technical flaws, establishing the standard as 
quickly as possible, and making the standard as readable as possible. For 
example, the German comments regarding "denote" raise an issue that pervades 
the entire document, but its resolution would require many more months and 
might result in a less readable document. 

Finally, note that not everyone is happy with conformant arrays. Both the 
United States and Japan stress their dislike of including an extension to 
Niklaus Wirth's Pascal in the first standard. The United States committee is 
now preparing to put out a draft proposed American National Standard for 
public comment which will not have any kind of conformant array parameters. 
Many countries also have criticised certain details of the feature as 'defined 
by the second DP; most objected to the use of parentheses in the actual 
(calling) parameter to specify it as a value (as opposed to "var") parameter. 
Some changes will therefore be made in the final version. 
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american national standards institute, inc. 
I 1430 broadway, newyork, n.y. 10018 
I (212) 354-3300 

ISO/TC 97/SC 5 N 
1981 May 08 



ISO 

INTERNATIONAL ORGANIZATION FOR STANDARDIZATION 
ORGANISATION INTERNATIONALE DE NORMALISATION 

ISO/TC 97/SC 5 
PR0GRA14MING LANGUAGES 
Secretariat: USA (ANSI) 

Summary of Voting on 97/5 N 595 - 
Second DP 7185 - Specification for the 
Computer Programming Language - Pascal 

The Secretariat issued this document for voting by 31 March 1981. To date 
the following votes have been received: 

'P' Members approve 4 Italy, Netherlands, Switzerland, United 
Kingdom 

'P' Members approve 7 Australia, Austria, Canada, Finland, France, 
with comment Germany, United States 

'P' Members disapprove 1 Japan 

'P' Members not Voting 6 China, Hungary, Norway, Romania, Spain, Sweden 

'0' Members approve 1 Poland 

'0' Members approve 
with comment 1 Czechoslovakia 

Comments received : 

Australia - Attachment A 

Austria - Page 35, paragraph (e) (1) first line: Specification instead of 
specifi^cation 

Canada - Attachment B 

Czechoslovakia - Attachment C 

Finland - Attachment D 

France - Attachment E 

Germany - Attachment F 

Japan - Attachment G 

USA - Attachment H - 2 parts 



DOCUMENT ISO/TO 97/SC 3 N393 



ISO/DP 7185 - Specification for the 



Computer Programming Language PASCAL 



ATTACHMENT A 



Comment of Australian Jlem"ber Body 

In recording a rote of approval on the al50YC ISO/DP, the 
Australian Member Body submits the following comment: 



The Australian vote in favour of the adoption of DP7185.1 expresses the view 
that the conceptual structure and definition of the DP are correct and 
appropriate for an International Standard, and takes into account the delays 
that have already arisen in the preparation and approval of a Pascal Standard. 

However, exainination of the DP has revealed a number of points which are not 
adequately defined by the text, though the intent is well-understood by those 
who have worked on this Standard. The following comments therefore represent 
our considered view of the editorial changes that must he made to the Draft 
Froposal so that it does say what is meant .- We believe that the changes will 
be non- controversial, and should be incorporated before the DP is sent for 
voting as a DIS. Generally the changes correct grammatical and punctuation 
errors, poor English expression, or omissions. 



POSITIVE COMtgNT 

Comment received on such documents is usually negative, since critical appraisal 
is sought. It should, however, be placed on record that comments received 
by the Australian Committee have praised two features of the definition which have 
raised controversy in the past: 

* the conformant-array -parameter, and 

* the restriction of a for-statement con trolled- variable to local 
simple variables. 

In addition, the improved formalism of the Draft Proposal was favourably received , 
and the view has been expressed .that an even greater use of formal definitions 
would have been welcome. 



Typographical Comment 



PROBLEM 

Australia draws attention to the poor presentation of DP7185, and in particular 
to the following features of the document: 

* The typefont (which is guessed to be that of a Decwriter) is very difficult 
to reacl in large quantities; its treatment of characters with descenders 
(for example p, q) is unacceptable in a professional document. 



* No underlining or italicising is used in the document, not even where such 
treatment would aid clarity by giving cues . Thus no headings are 
underlined or bold-faced, making it difficult to find places in the 
document. Also, notes should be in a distinctive type-face if possible. 
Particularly bad examples can be *f ound in section 6.9, where the sense 
of the words input and output are only determinable with difficulty: 

DP7185: ...applied to the required textfile output. 

better: ...applied to the required textfile denoted by the required 

identifier output 

or: ...applied to the required textfile output. 

RECOMMENDATION 

While sympathising with the problems associated with the preparation of this 
document, it is recommended that before the DP is sent out for a further vote, 
or for voting as a DIS, it should either be typeset or it should be typed with an 
acceptable word-processing system providing for good-quality typefonts. 



Introduction & Zero-Mumbering 



PROBLEM 

It is barbarous to start the numbering of sections in this document from 
zero, and offends against normal practice. 

In addition, the Introduction is nothing of the sort, but rather part of the 
prescription of section 1 (Scope of this Standard). 



RECOMMENDATION 



Delete the "0. INTRODUCTION" heading. 

Move the text contained in the now deleted Introduction to the end of paragraph 
1.1, page 2. 



Errors 



PROBLEM 

The definition of errov in section 3.1, page 3, is correct, but suffers from two 
defects. Firstly, the detection of errors is hardly to be regarded as "optional" 
in accepted English usage; rather the detection of errors may be elided by 
implementations which do not profess to offer the highest quality of implementation. 
Unless the meaning is expressed correctly, implementors will take the words in the 
most relaxing sense. > 

m 

The second flaw is more serious: the philosophy of errors is nowhere stated. j=. 
This is certain to cause confusion in future revisions of the Standard, and has 
been illustrated with the rapid switching of positions on goto-statements in 
recent drafts. Clearly this is not part of the Standard, but could be in a NOTE. 



RECOMMENDATION 

1. Alter the definition of error to: 



2,1 error , A violation hy a ■program of a requirement of this standard 
which a processor is permitted to tea:oe wndeteoted, 

2. Between 3.1 and 3.2 add the following NOTEs: 

HOTE. If it is possible to construct a program in which the violation 
or non-violation of a requirement of this Standard requires knowledge 
of the data read hy the program^ or of the implementation definition 
of implementation-defined or implementation-dependent features^ then 
violation of that requirement is classed as an error. Frocessors may 
detect and report on some violations of the requirement without such 
knowledge^ hut there always remain some cases which require execution 
or simulated execution^ or proof procedures with the required knowledge. 
Requirements which may he verified without such knowledge are not 
classified as errors. 

NOTE. Processors should attempt the detection of as many errors as possihle^ 
and to as complete a degree as possible. Permission to omit detection is 
provided for implementations in which the detection would he an excessive 
burden^ or which are not of the highest quality. 



Definition of Processor 



PROBLEM 

The definition of processor is incorrect. A processor can only be regarded 
as a complete system for processing Pascal programs, and parts of a complete 
system cannot be regarded as a "processor" . 

A partial processor (eg a compiler, as suggested by the DP) is ^ free of all sorts ^ 

of semantic constraints; even with a run-time system it can still shed responsibility 

to a host operating system, or even to hardware design. 

If validation of Pascal processors is to be possible, this definition must say 
what has been assumed all along: a Pascal processor is an entity that accepts 
Pascal programs, and "executes" them. 

RECOMMENDATION 

Replace definition 3.H, page 3, by: 

Z.4 processor . A system or. mechanism which accepts a program as inputs 
prepares it for execution^ and executes the process so defined with 
data to produce results. 

NOTE. A processor may consist of an interpreter,, a compiler and 
run-time system^ or other mechanism ^ together with an associated 
host computing machine and operating system^ or other mechanism for 
achieving the same effect. A compiler in itself j for example ^ does 
not constitute a processor. 



Required^ Predefined & Predeclared 



PROBLEM 

There are a collection of problems with the terms required , predefined , and 
predeclared in the DP. These are detailed below. 

* The terms predefined and predeclared are not defined in the DP, and 
are not common English words. Their meaning in the context of the 
DP is thus uncertain, and only determined by Pascal tradition. 

* The term required is defined by 6.2.2.10 and nowhere else. A definition of 
the meaning of the term is necessary, especially as it does not mean 
predefined nor predeclared. 

* Jn clause M- an as sumption relating to the denotations of required 
identifiers in program fragments in the DP is stated, but in terms 
of "predefined or predeclared". Not only are these not defined, but 
Pascal tradition would then exclude input or output from the set. 



RECOMMENDATIONS 

1. Replace the following sentence in section 4, page 3, lines 18-21: 

Any identifier that is defined in clause 6 as the identifier of a 
predeclared or predefined entity shall denote that entity hy its 
occurrence in such a program fragment. 

by: ^ 

Any identifier that is defined in clause 6 as a required identifier 
shall denote the corresponding required entity hy its occurrence in 
such a program fragment. 

2. Add at the end of the first paragraph of 6.1.3, page 6: 

Identifiers that are specified to he required shall have special 
significance in Pascal (see 6.2.2.10 and 6.10). 

3. Add the following sentence after the last paragraph of section 6.3, page 11: 

required constant-identifiers are specified in 6.4.2.2 and 6.7.2.2. 

M-. Replace the sentence following in section 6.4.1, page 12; 

The required types shall he denoted hy predefined type-identifiers 
(see 6.4.2.2 and 6.4.3.5). 

by: 

The required type-identifiers and cojrresponding required types are 
specified in 6.4.2.2 and 6.4.3.5. 

5. Replace the only paragraph of 6.6.4.1, page 38, by: 

The required procedure-identifiers and function-identifiers and 
the corresponding required procedures and functions shall he as 
specified in 6.6.5 and 6.6.6 respectively. 

6. Add at the end of section 6.2.2.10; page 10: 

See 6..1.3^ 6.4.1 and 6.6.4.1. 

NOTE: The required identifiers input and output are not included^ 
since these denote variables. 



7, Replace the firgt sentence of the gecond paragraph of section 6,10, page 6§; 

Th^ ooaurvem^ of the identifier input or the identifier output as a 
parameter shalt Qomtitui^e it§ d&fining^point for the region 
that is the progrm-hlpak a§ a variahteU'dentifi'er of the required 
type denoted text. 

The oQcmrrenoe of the required identifier input or the required 
■identifier output as a program parameter shall aonstitute its 
defining -rpoint for the region that is the progr.m-i>lock as a 
Vapiaite^identifier of the required type denoted "by the required 
type^identifiev text, 

8, The example at the end of 6.6.2 violates the requirements of section i4- by 
using .the required identifier ne^ Kith a denotation that is not the required 
procedure. Though the usage is obvious, it is inconsistent, and the example 
shou4.d be rewritten with the identifier new replaced by estimate. 



Language Levels 



PROBLEM 

The DP defines two "levels" of the language, which it numbers. 0 and 1, There are 
two objections to this scheme; 

* Numbering an enumerated set of objects 0 and 1 is a barbarism in the 
English language , however mathematically attr.active it might be. Levels 
1 and 2 would be far preferable. 

* The level chosen to be level 0 is in fact close to what is popularly known 
as Standard Pascal , whereas level 1 contains an extension which is at 
present not common. It would therefore be preferable to refer to the 
"levels" by names which indicate their usage. 

The Australian recommendation is to adopt the latter course, using the names 
Standard Pascal and Extended Pascal to distinguish the levels . Not only does 
this make the distinction clear, it has the following advantages: 

* Vendors of Pascal products can more readily identify their conformance 
as being to "Standard Pascal as defined in IS07185" etc. 

* Future revisions of the Standard can retain Standard Pascal as a subset, 
by confining extensions to Extended. Pascal . 

* Implementors who choose not to implement the extension for conformant 
arrays will not be saddled with an implied deficiency ("only level 0"). 



RECOMMENDATION 

Replace the phrases at teoet 0 and at tevet 1 in section 5.1, page if, and in 
section 5.2, page 5 by as Standard Pascal and as Extended Pascal respectively. 

Replace the NOTE in section 5, page k by: 

NOTE, There are tiDO levels of compliance j known as Standard Pascal and 
Extended Pascal, Standard Pascal does not include conformant array 
parameters. Extended Pascal does include conformant array parameters. 



Replace the several occurrences of 

Ido") not apply to level 0 
in sections 6.6.3.6, page 35; 6,6,3,7, page 35; and 6.6.3,8, page 37 (and. any other 
occurrences) by; 

Ido^ not apply to standard Pascal 

Wherever any further occurrences of levels 0 or 1 appear, replace them by appropriate 
text; a full cross -reference was not available to us to check that all have b6en 
detected . 

Detection of Violations 



PROBLEM 

Section 5.1(e) requires the detection of violations that are not errors. However, 
it does not require that the detection by the processor be reported to the user 
of the processor. 

Secondly, it is unreasonable for the Standard to insist on processors reporting 
all violations. Parasitic effects of one error may mask some violations and often 
do; other processors often have error-limits. Interpreters, of course, adopt a 
different approach to error-detection. The thinking an this section is confused: 
the appropriate requirement is that the processor be able to classify programs 
into two' classes: 

1. The class of compliant programs, and 

2. The class of non-compliant programs. 

However, if the processor has not completely examined a program text, as .occurs 
in processors with an error limit, processors which abort under some table overflow 
conditions, or direct execution or interpreter machines, then a third response 
is permissible: 

3. The><:lass of programs in which no non-compliant feature has yet been 
detected, but which has not yet been completely examined. 

Processors should report accordingly, and this should be the Standard's stance. 
More information about the source of non-compliance in such programs cannot be 
legislated for as it is heavily dependent on technique, 

RECOMMENDATION 

x\cplace section 5, 1(e), page 4, by: 

(e) determine whether or not a program violates any requirement of this 
standard that is not designated an error and report the result of this 
determination to the user of the processor. In the case where the 
processor does not examine the whole of the program^ the user shall he 
notified that the determination 'is incomplete whenever no violations have 
"been detected in the program text examined. 

Add a NOTE at the end of Section 5.1, page 5: 

NOTE, Normally a processor which consists of a compiler and ancillary 
components will he able to classify programs into the compliant or 
non-compliant categories in accordance with clause 5,1 Ce) after examining 
the program text. However ^ in cases where the compilation is aborted 
due to some limitation of tables^ etc^ on incomplete determination 
of the kind "No violations were detected^ hut the examination is 
incomplete" will satisfy the requirements of clause 5.1(e). In a similar 
manner an interpretive or direct execution processor may report an 
incomplete determination for a program of which all aspects have not 
been examined. 



FRROR-RfPORTpe 



PR03?igM 

The "regyipjement stated iij sectioB 6 ,l-.(f) 49^3 got -pequire that all the .statements 
relating to e??rpr-r,^03?tin^ be -easy to find, ,aijd' indeed they may be obscurely hidden 
in an obscup.e part of the documentatioij _and widely s^iiatteped... This is undesirable, 

REeOMMENDATI-Oy 

^dd the fGilo^^ing to the end .of S^iCf), pages h & 5i 

Jf piolaHgns that gre .desigmted ,as jQTg treated in the manner 

cLesopiped pn §.l{f)-(l)j 'bhen 4 TiPte vgfgveneing such treatment shall 
ffppi^m* in a e^pccrate a^^gtim <?f the aaegmpmying domm&nt. 

Restrictions and Cowflianpe of PRoefssoRs 



PROBLEM 

Though the BJP addresses the probl.ejn9g of specifying extensions in section 5, 1(g), 
ijoj^hepe is it stated ijjiat action j)rp,cessprs mu§t take jjith respect to restrictions, 
It is possible tg arjgue that restrictions .ar^e -possijple, and processprs must comply 
j^ith all re§uirBra^t§ of ^rhe StanCapd if they a3?ia to claim ppmpliaijee with it , but 
.Australia consi-ders that this is unrealistic ^ Pppee§s.prs will contain Restrictions, 
#yen if pn.ly a few. 

In §.ddition, ignoring the problem effectiyely prph.ihits any new reserved words, since 
the§e Restrict the set of permissible ident.if .iers , thus .eneour aging overloading 
,pf existing oper^ator^^ woy'ds , and pther .extension mechanisms, 

Australia argnes tjiat tbe shojild jcpntain ,a statement controlling the use of 
cpmpliance §tatera,entg, which specifies a^itipn with respect tp restrietipns , 

RECOMMEN.DATIQN 

Md 'at^the~.end pf §ecti.©n 5,1^ page bjit not .dependent on (i)", the following; 

A proo,e,s.sor that purpgrts to complLyj wholly or partiallyj with the 
rgjquirements of thi.s standard §hatt dp so only in the' following terms, 
A c.omplianp^ statement may he produced hy the prgaessor as a consequence 
of using the prgiBe^§or^ may inQ%yded in agoompmying docm&ntatign. 
If the ppgc^§!sgz' ggmplie§ in all respects with the requirements of this 
^'pm4ard the ogmpliangg §tatement ^'Hall he: 

<This prpc?esspr> Gpmplia.s with the requirements pf <Standard Pascal> 

as stfiited in 1307185., 198=-, 
If the prggessor agmplies With some hut not all gf the requirements of 
this ^tar^ard then it §hal% not use the ahgpe statementj hut shall instead 
us^ the following compliance statements 

sfiTb.is prpcesg.pr> jcomplies with the y.equirements pf <Standard Pascal> 

as stated in Ii07185, 198- , with the following exceptions.: 

•<fpllpwed by .a reference to, or §l cpiDplete list pf , the requirements 
pf the standard with wbipb the prpcessor 4oes not comply.. > 
In hofh cases the text <Tbis prpcessoj??- may be replaeed by an unambiguous 
name identifying the processor^ and th^ te^t <Standard Pascal> may 
be replqged by Extended Pascal if appropriate to the level of implementatign, 

IfOT^, Progessors that do not ggmply fuHy with the requirements of the 
standard are wt required to gi'^e full .details of their failures to gomply 
in the ggnrplimg^ statments a brief reference to agpompanying doaumentatign 
Whioh ggnl^ins a ggmplete l-ist in iBuffigient detail tg identify the 
def&gt§ i§ sufficient. 



Complying Programs 



PROB^iEM 

The HOTE at the end of section 5.2, page 5, is grossly misleading. The results 
produce.d under the conditions stated certainly are required tp be the same for 
,ai class of programs, while other classes have epnstraints which permit different 
results. The resultant confusion rg^uirps th.at the Standard say precisely what is 
implied,, not ,aii incorrect statement. 

RECOMMENPATIOy 

■:P'el^te" the N0TE at the end pf 5,2, page 5, and r.eplace it by the fpllowing: 

fl€T^. A program that gcmpties with the requirements gf this clause may 
rely on partigulair implementation-rdefined ■values or features^ and it may 
gontain errors which will only be evoked by particular data values, 

IfOTE. The requirements for gomptiant prggrams and compliant processors do 
not require that the results produced by a compliant program are always 
the same when processed by a compliant prggessor. They may be^ or they 
may differ^ or potential errors may he epgkedj depending on the program, 
^e simplest program to illustrate this is: 

prggrm x (output); begin writelnCmaxint div (maxint^ZB? 67 ) ) end. 

Character-string^ 



PROB]LEM 

The des.cription of character-strings and the denotation of string-elejnents 
in 6,1,7, page 7, is .confusing, and omits to give the apostrophe-image a value 
of char-type, except by implicatipn* AlSP the term "string of characters" is 
used in a .context where "character -string" is more appropriate. 



RECOMICNDATIQ.N 

Delete' the text paragraph in 6,1,7, page 7, and replace by: 

e,l,7 Character-strings , A character-string containing a single 
etring^lement shall denote a valm of the required char-type 
(see 6, 4,2,2), A character- string containing more than one 
string^ element shall denote a value of a string-type (see 6,4, S, 2) 
with the same number of components as the character-string contains 
string-elements, ^ach string- element shall denote an implementation- 
defined value gf the required chgr-^type^ suho&ct to ihe restriction that 
ng such value may be denoted by more than one string-element, 

NOTE. Conventionally^ the apostrophe-image is regarded as a substitute 
for the apostrophe character j, whigh gcmnot he a string^'Character , 



SUBSIPIARY NOTE 

The required values pf char-tjnpe are: 



the ten digit-values denoted by '0' ^. '1' , '2' , . , , '9» 


5,4. 


.2.2 


the space -value denoted by ' ' 




.3.5 


the number-values denoted by •+','-','.' 


5,9, 


.H,x 


the exponent- value denoted either by 'e' or 'E' 


6.9 


.4.5.x 


whatever case letters are required for 'True' and 'False' 


5,9, 


,4,5 



In the preceding redraft, the value denoted by the . apostrophe-image is added 
as a required value, but it need not denote a value whose graphical 
representation is indeed the ' character. This is exactly the saine situation 
as exists with the other required values: the external graphical representations 
of the values are not controlled. 

Lexical Alternatives 



PROBLEM 1 

The second NOTE in section 6,11, page 58, is incorrect. The Standard does indeed 
exclude the existence of other symbols, since processors which accept them 
are probably (depending on the symbol) accepting programs which are not compliant 
Pascal programs, and therefore contain extensions. 

RECOMMENDATION 

Delete NOTE 2 on page 68, and the numeral "1" from the first NOTE. 



PROBLEM 2 

This whole section is at variance with section 6.1, which sets out the requirements 
for lexical tokens. Properly, it belongs there, not here at the end of the 
Standard, which is simply where Niklaus Wirth put it originally in the User Manual. 



RECOMMENDATION 

Delete section 6.11 and insert a new section 6.1.9 as follows; 

6,1.9 Lexical altemg-tives . The representation for lexical tokens and 
separators given in sections 6.1.1 to 6.1.8 constitutes a reference 
representation for these tokens and separators which shall he used for 
program interchange. 

To facilitate the use of Pascal on processors which have a character set 
which will not support the reference representation^ the following 
alternatives ore provided. All processors which have the required characters 
in their charaater set shall provide both the reference representations 
and the alternative representations^ and the corresponding tokens or 
separators shall not he distinguished. 

The alternative representations for tokens are given helow: 

Reference token Alternative token 
A , @ 
[ (. 
] 0_ _ _ 

liOTE. The character + which appears in some national variants of the ISO 
character set is regarded as identical to the character a. 

The alternative foims of comment are all forms of comment where one or 
both of the following substitutions are made: 

Delimiting character Alternative delimiting 
pair of characters 
{ (* 
} *) 



WTE. A comment may thus conmence with "{" and end with or 
commence with "(*" and end with "}". 



Identifier and Label Terminology 



PROBLEM 

The following problem was drawn to Australia's attention by W.Price, but 

the solution differs slightly from that proposed. It is however based on the 

comments received, but modified to cope with labels. 

In section 6.2.2 the word identifier is used with at least four meanings. The 
one attached to the syntactic definition should be left untouched, but the 
others need to be disting\iished to clarify the DP. Labels are equally affected. 



RECOMMENDATION 

1. Change the second sentence of 6.1.3, page 6, to read: 

All characters of an identifier shall he significant in distinguishing 
between identifiers. 

2. Replace clause 6.2.2.5 by: 

When an identifier or label has a de fining-point for region A 
and an identifier or label that cannot be distinguished from it 
(see 6.1.3 and 6.1.6) has a ds fining-point for some region B enclosed 
by i4j then region B and all regions enclosed by B shall be excluded 
from the scope of the de fining-point for region A. 

3. Replace clause 6.2.2.7 by: 

The scope of a de fining-point of an identifier or label shall 
include no de fining-point of another identifier or label that 
cannot be distinguished from it (see 6.1.3 and 6.1.6). 

Change 

...all occurrences of that identifier or label shall be designated 
applied occurrences . . . 
in clause 6.2.2.8 to read : 

. ..each occurrence of an identifier or label which is indistinguisdble 
from the identifier or label of t/ie de fining-point (see 6.1.3 and 6.1.6) 
shall be designated an applied occurrence of that identifier. . . 

5 . Change 

... a type -identifier may have an applied occurrence in ihe 
domain-type. . . 
in clause 6.2.2.9 to read: 

...an identifier may have an applied occurrence in ihe type-identifier 
of iihe domain-type . . . 

Function St^listics 



PROBLEM 

An example of a procedure-and -function-declaration-part is given in section 6.6.2, 
pages 31 £ 32. Amongst the examples is an example of functions using mutual 
recursion, and illustrating the forward directive. This example is written with 
poor stylistics, in that: 

* the mutuality of the recursion is disguised by the layout, in which 
the two procedures are written differently; 

" Apart from the Standard-oriented comment at the top, the mutuality of 
the recursive references is not documented; and 

* a pseudo-repetition of the parameter li'st of ReadOperand suggests that 
this poor practice of repeating information (possibly erroneously) be 
copied . 



RECOMMENDATION 

Replace the text beginning "{This example of ..." to the end of the section by: 



{ The following two functions analyse a parenthesized expression and convert it 
to an internal form. They are declared forward since they are mutually recursive 
they call each other. } 
function ReadExpression : formula; 
forward ; 

function ReadOperand : formula; 
forward ; 

function ReadExpression; { See forward declaration of heading. } 
var 

this : formula; 
begin 

this := ReadOperand; 

while IsOperator(nextsym) do 

this :='MakeFormula(this, ReadOperator , ReadOperand); 

ReadExpression := this 
end; 

function ReadOperand; { See forward declaration of heading. } 
begin 

if IsOpenParenthesis(nextsym) then 
begin 

SkipSjmibol; 

ReadOperand := ReadExpression; 
{ nextsym should be a close-parenthesis. } 
SkipSymbol 
end 
else 

ReadOperand := ReadElement 

end; 



Conformant Array Syntax 



PROBLEM 

The syntax for index -type-specif ication does not use bound-identifier. 



RECOMMENDATION 

Replace the syntax for this in section 6.6.3.7, page 36, lines 16-18, by; 

vridex-ty-pe-specifioation = 

boimd-'ident'if'ier bound-identifi-er 
":" ord'Cnat-type-'Cdentif'Ler . 



For-Statement Specification 



PROBLEM 

In 6.8.3.9, pages 55 £ 56, a circular argument is introduced in following the 
consequences of making the limit expressions el and e2 "compatible" rather than 
"assignment-compatible" with the control-variable. Firstly, the fourth sentence 
of the second paragraph states: 

The jDatue of the finat-var'idbte shall be assignment-oanpatible with the 

control-variable when the initial-value is assigned to the control-variable. 
Later, the paragraph goes on: 

Apart from the restrictions imposed by these requirements ^ the for-statement 
for V := el to eB do body 

shall be equivalent to 

and this shows that an over-riding restriction is specified in terms of a s\ibsidiary 
specification (which is valid only where not in conflict with the previous 
restrictions). Secondly, the similar restriction on el is not mentioned at all, 
and is only implied by the equivalent program-fragment. 

The problem is derived from the decision to abandon "assignment-compatibility" 
as the prime requirement for the limit expressions under all uses. However, if 
that decision is left, then it can readily be seen that the proper restriction is 
related to the execution or not of the controlled statement ("body"), not of 
components of a (virtual) equivalent fragment, and its execution -sequence. 

RECOMMENDATION 

Delete the sentence given above (first italicised entry) and replace it by: 

The initial-value and the final-value shall be assignment compatible 
with the type of the controlled-variable if the statement of the 
for-stqtement is executed. 



Trivial Mistakes 



PROBLEM 

The DP contains several trivial punctuation and grammatical mistakes. 



RECOMMENDATIONS 

1. Delete second comma in second sentence of 6. 4. 4, page 21. 

2. Delete comma in NOTE on page 16 of 6.4.3.2. 

3. In 6.4.3.4, page 19, line 9, insert the word type so that the 'first sentence 
of the paragraph begins*: 

For every ordinal-type Sj -there exists an unpacked set type 
designated ... 

4. In 6.4.3.2, page 16, replace characters by string-elements and left to right 
by textual in lines 7 and 8 respectively. 

5. In 6.5.1, page 24, line 3, delete the text 

( current) 
or remove the parentheses. 
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We approve DP 7185 as presented, though making 
the following comments of an editorial nature: 



COHHENT ON Error Handling (5. If) 
STATUS Editorial 
PROBLEM STATEMENT 



Parts 2 and 3 of this section (5»lf) say 

*2) the processor shall have reported a prior warning that 
an occurrence of that error was possihlef 
3) the processor shall report the error during preparation 
of the prodrani for execution?* 

The term 'prior warning' presumably means a uarnin^ prior to 
execution* That isi this warning occurs during preparation of 
the Program for execution* Rewording part 2 makes it clearer 
that parts 2 and 3 deal with distinct* but relatedi issues* 

PROPOSED CHANGES 

Replace 5Af part 2 with 

*2) the procesor shall report during preparation of the 
program for execution that an occurrence of that error was 
possible! • 



COMMENT ON Numbers (6.4.2.2) 
STATUS Editorial 
PROBLEM STATEMENT 

This section saas 'The values shall be a subset of the whole 
numbers? denoted as specified in 6.1.5 by the si^ned-intdder 
values (see also 6*7.2.2).' The values are denoted not by 
values* but by the syntactic class sidned-inte^er* 

PROPOSED CHANGES 

In section 6 ,4. 2 .2* replace '...by the sidned-inteder 
values**.' by '...by sidned-inteser * » ♦ ' and replace ' . . rby 
the sidned-real values.* by '...by sidned-real r * « 



COMMENT ON File-types (6.4.3.5) 
STATUS Error 
PROBLEM STATEMENT 

In part d of the definition of a seauence-typei the case in 
which y is empty and x is non-empty is not covered* 

PROPOSED CHANGES 

Replace 

'If >\ is the empty seouencer then x=y shall be true if and 
only if y is also the empty seauence*' 

with 

'If either x or y is the empty seauence* then x=y shall be 
true if and only if both x and. y are empty* ' 



COMMENT ON Exa«ipl« in 6,6.2 
STATUS Pro^ra* Bud 
PROBLEM STATEMENT 

In function ReadEMpressiom the statenent 

'this t= MaKeForifcula (thisi ReadOperatorf ReadOperand) » ' 

would, not be standard-conforfcind if both ReadOperator and 
ReadOperand we're functions that advance the input stream - it 
relies on the lefi-to-ridht evaluation of the actual 
PEraiueters» 

PROPOSED CHANGES 

Replace 'function ReadExpression endi* with 

•function ReadExpression » formula) 
var 

this * forjuulai 
op I operaiori 
bed in 

this != ReadOperand* 
while IsOperator (nextsy») do bedin 
op J= ReadOperatorJ 

this := MaKeFormula (this? opi ReadOperand)? 
end/ 

ReadExpression ♦= this 
endi ' 



COMMENT ON Actual parameters with pacKeFd tapes (New 6.6.3.1 and 6.6.3.7) 
STATUS Editorial 
PROBLEM STATEMENT 

Does the sentence 

'An actual variable parameter shall not denote a component 
of 3 variable that possesses a tape that is designated 
packed. ' 

mean that the component's tape must not be packed* or that the 
variable's tape must not be packed? The latter interpretation 
is the desired one. 

PROPOSED CHANGES 

In 6.6.3.1 replace the ambiguous sentence with 

'An actual variable parameter shall not denote a component 
of a variable where that variable possesses a tape which is 
desidnaled packed*' 

SimilarlHj in 6.6.3.7 replace 

'...shall not denote a component of a variable that 
possesses a tape that is designated packed.' 



with 



'.♦.shall not denote a component of a variable where that 
variable posseses a tape which is designated packed.' 



COMMENT ON Conformant arraa parameters (New 6.6,3,7) 
STATUS Editorial 
PROBLEM STATEMENT 

This section (6»6»3,7) saas 

•,..and which shall have a component-tape that shall be 
that denoted ba the tape-identifier contained ba the 
conformant-arraa-schema in the 

conformant-arraa-parameter-specif ication and which shall 
have the index-tapes of the tape possessed ba the 
actual-parameters that correspond (see 6,6.3.8) to the 
index-taPB-specif ications contained ba the 

conf ormant-arraa-schema in the 

conformant-arraa-parameter-specif ication, * 

Since Pascal does not have true multi-dimension arraasi the 
sentence should be phrased in terms of nested conformant arraa 
schemasi 

PROPOSED CHANGES 

Replace the sentence tail Quoted above with 

'...and which shall have a component-tape that shall be 
that denoted ba the type-identifier or 

conformant-arraa-schema closest-contained ba the 
conf ormant-arraa-parameter-specif ication and which shall 
have the index-tape possessed ba the actual parameters that 
correspond (see 6,6,3,8) to the single 

index-tape-specif ication closest-contained ba the 
conformant-arraa-schema in the 

conf ormant-arraa-parameter-specif ication , ' 

As is the case elsewhere* this definition applies to the 
lond-hand form of conformant-arraa-parameter-specif ications* 



COMMENT ON Assidnind-ref erence (6,5,1) 
STATUS Error 
PROBLEM STATEMENT 

The definition of assidnind-ref erence in section 6,5,1 does 
not saa anathind about actual parameters to reauired 
procedures other than read and readln. As it turns out* there 
is no real need since the notion of assidnind-reference is 
onla used in the definition of the for-statement* and the tape 
of the loop variable cannot be an arraa-i pointer-* or 
file-type, The term 'assidnind-ref erence' and its placement 
in 6.5.1 dive one the misleading impression that it is a 
Generally useful notion, 



PROPOSEII CHANGES 

If the term essidnin^-ref erehce is to remain specific to 
ordinal-types then either a) change the name to 
'ordinal-assidnind-reference' > or b) move the definition 
(6,5,1) to 6,8,3.9 (for-statements). 



If the term is to be made Generally usefuli then to the 
definition of assidnind-ref erence; append 

'(d) The variable is denoted by the variable-access in a 
procedure-statement that specifies the activation of 
the reauired procedure neu, 

(h) The variable is denoted by the third actual parameter 
in a procedure-statement that specifies the activation 
of the reouired procedure pacK» 

(i) The variable is denoted by the second actual parameter 
in a procedure-statement that specifies the activation 
of the reauired procedure unpack* 

(J) The variable is denoted (possibly implicitly) by the 
file-type actual parameter in a procedure-statement 
that specifies the activation of any of the following 
reauired procedures, readj readlm write? uritelm 
detf put; reset* reuritei and pade, 

NOTE* It is possible for a processor to determine all 
assidnind-ref erences in a statement without having to 
execute the prodrafc4 It is used in the definition of the 
for-statement» • 



COMMENT ON Implementation-Dependencies v,s. Extensions 
STATUS Error 
PROBLEM STATEMENT 

The standard is confused with respect to the nature and 
varieties of implementation-dependencies, Ue propose the 
following characterizations of the terms 

' implementation-dependerit' and 'extension** 

An 'implementation-dependent' aspect of the landuade is one 
for which the standard does not dive a complete definition* 
The intention is to allow the implementor a Greater decree of 
freedom than is normally the case* The following 
characteristics are desireableJ 

1) A standard-conf ormind processor may choose any 
implementation of an implementation-dependent feature as 
lond as it meets the reauirenents set down "by the standard* 

2) A standard-conf ormind processor need not document the 
way(s) in which the implementation-dependent aspects- of the 
landuade are implemented (c.f* implementation-defined 
aspects) , 



3) A standard-conformind proiram may not rely on the manner in 
which an implementation-dependent aspect is implemented* 



On the other handy the term 'extensions'* is used for '',,.any 
features accepted by the processor that are not specified in 
clause 6," The intention of talking about extensions in the 
standard is to allow an implementation to augment the landuade 
defined in the standard* Extensions have the following 
characteristics* 

1) Standard-conformind processors may support extensions* 

2) Standard-conformind processors must be able to process the 
use of any extensions '...in a manner similar to that 
specified for errors*. ♦' 

3) Standard-conformind processors must document all 
extensions. 

4) Standard-conformind programs must not use any extensions* 



PROPOSED CHANGES 

It would seem appropriate to define the term extensions in 
section 3 instead of in section 5,1 by addind 

'3.5 extension, A feature accepted by a processor that is 
not specified in clause 6*' 



In section 5tli we find 

■(i) be able to process in a manner similar to that 
specified for errors any use of an 
implementation-dependent feature. ' 

This clause in meaningless} any program containing an 
assignment statement can be said to use an 
implementation-dependent feature. The violation is in relyind 
on a particular implementation of an implementation-dependent 
feature. Since detection of such violations is impossible in 
General f clause 5,1 (i) should be deleted. 



A better wording for 5.2 (c) is 

•(c) not rely on any particular interpretation of 
implementation-dependent aspects of the landuade 
concomitant with the program's compliance level,' 



Section 6,1,4 talks about implementation-dependent directives. 
Calling such directives implementation-dependent is incorrect 
- the implementor would not even have to document them! These 
are extensions - and the standard has adeauate constraints on 
extensions. Therefore* delete the sentence .'Other 
implementation-dependent directives may be provided.' and 
change 



■NOTE* On many processors the directive external is used to 
specify that the »..' 



to 



•NOTE* Many processors provide* as an extension? the 
directive external which is used to specify that ♦4.* 



The impleiuentation-dependencies mentioned in sections 6i7*2«li 
6»7.3/ 6»8f2t2; and 6«8.2i3r are true 

implementation-dependencies - no changes are needed. 

As su^£(ested in ariother comnientf the effect of inspecting a 
textfile to .which paSe have been applied should be 
implementation-def inedi not implementation-dependent* 

In section 6ilO ue find 

'The binding of the varisbles denoted by the program 
parameters to entities external to the program shall be 
implementation-dependent! except if the variable possesses 
a file-type in which case the binding shall be 
implementation-defined* ' 

As is the case with directives* we don't want the implementor 
doind off and providing non-file-type program parameters 
without documenting themi this should be called an extension* 
Replace the above sentence with 

'The variables denoted by the program parameters shall 
possess a file-type and the binding of the variables to 
entities external to the program shall be 

implementBtion-def ined» ' 

If it is still deemed necessary to mention the common 
extension; extend the note as follows! 

'NOTE! The external representation of such external 
entities is not defined in this standard; nor is any 
property of a Pascal program dependent on such 
representation* As an extension; many processors permit the 
variables denoted by the program parameters to possess a 
type other than a file-type »' 



COMMENT ON If statements (6*8,3.4) 
STATUS Editorial 
PROBLEM STATEMENT 

This section says "An if-statement without an else-part shall 
not be followed by the token else." It is only a problem if 
an if-statement without an else-part is IMMEDIATELY followed 
by the token else* 

PROPOSED CHANGES 

Change the sentence to read! 'An if-statement without an 
else-part shall not be immediately followed by the token 
else.' 



COMMENT ON Procedure pade (6.9.6) 
STATUS Editorial 
PROBLEM STATEMENT 



•The effect of inspecting a textfile to which the pade 
procedure was applied during feneration shall be 
implementation-dependent.' It would be more appropriate if 
this aspect was implementation-defined; .not 

implementation-dependent. This would also be consistent with 
stance taken in 6*10 where the effect of the application of 
reset or rewrite to either input or output was classed as 
implementation-defined * 

PROPOSED CHANGES 

Change the sentence toJ 'The effect of inspecting ... shall be 
implementation-defined. ' 



COMMENT ON Terminating execution of programs (5.1 i 3) 
STATUS Editorial 
PROBLEM STATEMENT 

Section 5.1; part i; subpart 3 says 'the processor shall 
report the error during execution of the program; and 
terminate execution of the program.' An implementation should 
be free to decide (and document) what form of corrective 
action; if any; will he taken in the event of a 
runtime-detected problem, For example; the processor mifht 
want to ask the user what value his uninitialised variable 
should have; and then resume execution. 

PROPOSED CHANGES 

Change the sentence to} '4) the processor shall report the 
error during execution of the program.' 



Comment on Value Conforinant Arrays .(6»6.3.7) 
Status: technical comment 
Problem Staten^ent : 

An actual -parameter corresponding to a conformant-array-parameter- 
specification is allowed to be an expression (that is not a variable- 
access). This results in copying of the value of the actual -parameter. 

This approach is conceptually inappropriate,. inconsistent with 
the rest of the language, and error-prone. In PASCAL, it has been 
the programmer of the procedure declaration who has decided (by choosing 
between the variable and value forms of formal parameter specifications) 
whether a local copy of an actual -parameter is necessary. This 
responsibility should not fall on the callers of a procedure because, 
in principle, they need only concern themselves with what the procedure 
does, and should not be concerned with how this is done. If 
parenthesization of an actual conformant array parameter is by 
accident omitted, the result will often be a subtle logical error 
because of unexpected storage sharing, with no compile-time or 
run-time warning. 

Proposed Changes : 

.1. Allow value as well as variable forms of conformant-array- 
parameter-specifications . 

2. Require an actual -parameter which corresponds to a variable 
conformant-array-parameter-specification to be a varriable-access. 

3. Modify the restriction in the last paragraph of 6.6.3.7 to 
apply only when the actual -parameter corresponds to a value 
conformant-array-parameter-specification. 



ATTACHMENT C 



Czechoslo"vak commerits of an editorial nature on docuinent 
ISQ/TC 97/SC 3 N ^95 - DP 7183 

1) In our opinion, the incorporation of levels 0 and 1 into 
the specification of Pascal in fact defines two programming 
languages, being inconsistent with the need cf portability 
of programs. 

V7e suggest therefore to retain one level of compliance only, 
preferably level 1 (including conformant array schema) to 
force compiler producers to include this required feature 
into their products, 

Z) In section 6, 4,3. 4 a statement limiting the largest and 
smallest values of the base-type was deleted. We are 
convinced that such limits exist in each implementation 
and are usually low. 

We suggest to add a statement to section 6.4.3,4, stating 
an existence of limits of the cardinality of canonical sots 
(those limits being implementation-defined) and requiring 
their minimal range to allow for set of char, 

3) The behaviour of the procedures read and readln is not 
satisfactorily resolved when reading integer- or real-type 
values. 

We suggest to adjust parts (c) and (d) of section 6.9,2 in 
such a way, that if rest of file being scanned for integer 
or real values consists of spaces and end-cf-lines only, 
then reading shall cease, eof and eoln being true and value 
of variable v being left undefined, 

4) The production rule for procedure-statement conflicts with 
the definition of parameter-lists for procsdures read, readln 
write, writeln. 

We suggest to formally complete the production rule for 

procedure-statement as follows: 

procedure-statement m 

procedure-identifier jactual-parame ter-list J / 
read-procedure-identifier read-parameter-list / 
readln-procedure-identif ier readln-parameter-lis t / 
write-procedure-identif ier write-parame ter-lis t / 
writeln-procedure-identif ier writeln-parame ter-lis t , 



ATTACHMENT D 



COMMENTS OF SFS ON DP 71 8 5 "SPECIFICATION FOR THE PROGRAMMING LANGUAGE 
PASCAL" 

finnish comments are ^ainly based on the paper prepared 
at the Helsinki University of I'echnology and made by 
the PAX-Pascal Group (Jukka Korpela ^.Pertti Tapola, 
Timo Larmela, Ahti Planman) . I have collected some 
other opinions listed below. 

Layout of the draft is incomplete: It's very difficult 
to find starting points oh chapters from the text, 
because there are no extra erYty lines between chapters. 
Darker chapter headings or headings written with 
letters differing from normal text would help. Contents 
(page 1) is incomplete and doesn't include all chapter 
headings. Index (pages 77-82) is very uncomfortable 
to use because of several references to same objects 
(for example term "variable" has 23 references) . 
References should be grouped into "sub-terms" or/and 
main references should be unde'rlined or written with 
different type. Some terms (for example "comment") 
*are missing ► 

In chapter ^.1.2 characters " i" and "} " are missing 

from the production special-symbol. It would also be 
usefull to have reference to the chapter 6.11 (Hardware 
representation) where alternative symbols are listed. 

In chapters 6vl.8, 6.4.3.1.^2 and 6.5.3.2 references 
to chapter 6.11 as above. Thats important for 
Scandinavian Pascal users, because we use Scandinavian 
letters X,0,A having same code as f Just a 

few terminals have characters [ and 



In chapter 6.4.3.1 order of productions is wrong, 
injsome other chapters too. 

In chapter 6.4.3.3 (record type variant part) it 
should be possible to have as an element of case- 
constant-list some kind of subrange expression of 
form case-constant ".." case-constant. Same form 
is also usefull in case-statement (6.8.3.5). In 
addition this form of case-co^tant is compatible with 
set expressions. 

Basic principles of garbage collection system should 
be formulaten in spite of it's hardware-dependence. 
Thats important because different implementations 
have different properties (e.g. what to do with dynamic 
allocated variables referenced with pointers written 
into file-variable. 

Tampere 19 81-03-16 
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Foreword 



This paper has been prepared at the Helsinki University of 
Technology Computing Centre. It does not present any official 
statement of any organization but reflects the observations, 
suggestions, and opinions of several specialists actively 
working on the fields of systems and applications 
programming, including -Pascal compiler "writing and 
maintenance, and teaching of Pascal. 



CHAPTER 1 
STRUCTURE AND TERMINOLOGY 



1.1 OVERALL STRUCTURE AND COMPLETENESS OF THE DRAFT 

The draft being commented contains significant improvements 
to the first draft, and is, in general, sufficiently complete 
and well-structured t« become a standard. 

The main disadvantage is the alteration of terminology and 
style for semi-formal definitions. This draft, as well as the 
first draft, contains a great amount of terminology which is 
not commonly known and used in the Pascal community, or even 
differs from the terminology currently in use. 

For example, the definitions in clause 6.2.3 are difficult to 
understand, and assumably extremely obscure to ordinary 
Pascal programmers, What makes them strange for experts too 
is the obvious attempt to avoid references to implementation. 
The definitions become understandable to a compiler writer 
when the "within" relation is conceptually associated with 
what is known as static link in implementations. 

On the other hand, the last note in clause 6.6.3.7 makes a 
rather explicit reference to implementation, using the notion 
of activation record. 

It is difficult to define some features of Pascal in a m.^*ir» - 
which is both general (not referring to a particular mc fioo 
of implementation) and understandable, -and possibly tb-? 
difficulty is inherent. 

In spite of the criticism above, the- difficulties of 
specification should not be allowed to postpone the 
standardisation of Pascal. Probably a sufficient solution 
would be to add a few notes referring to implementation 
aspects, particularly to clause 6.2.3 but possibly also to 
clauses 6.6.6.3 (about the fact that in practise the address 
of an actual variable parameter is passed and all references 
to the formal parameter use the address passed), 6.6.3.4 anc 
6.6.3.5 (an analogous note would be useful), 6.6.3.7 (e.g. 
that both the address of an actual parameter and the actual 
index bounds are passed), 6.8.2.4 (a nonlocal GOTO requires 
an appropriate context switching), and 6.8.3.10 (the addiess 
of a record variable in the record variable list of a WITri 
statement is calculated once only) . 



The structure of the draft is similar to previous 
descriptions of Pascal. However, the order of presentation 
should be reconsidered in the following respects. 

1. Clause 6.3 bears the title Constant-definitions, although 
it also describes constants. Splitting it into two part? 
would not be worth while ^ but 'the title should be 
changed . 



2. Similar comment applies to clause 6.4. However, the 
importance of the subject and the length of the clause 
suggest that the clause should be divided into several 
major sub-clauses of clause 6. At present clause 6.4 
describes type definitions, denotations of types, and. the 
meanings of type denotations. These subjects should he 
treated separately. 

3. Rules for procedure and function declarations in clause 
6.6 exhibit great* similarity of structure. Integra,tion of 
the specifications would increase readability and reduce 
the size of the standard. 



1.2 THE STABILITY OF PASCAL 

The two major changes stated in the foreword are useful. The 
first one is to be regarded as a necessary language change. 
The second one is rather strong . extension to the language 
defined .by Niklaus Wirth but is very useful. The solution 
adopted, to make it a sort of "recommended extension", is 
elegant. 

They are some features of Pascal in which the draft differs 
from Wirth 's definition and/or most current implementations 
in a manner which makes them important for ordinary users. 
Mentioning them in the foreword would be worth while. This 
applies in particular to type compatibility rules in the 
broad sense, ^ the semantics of WITH statement, the meaning of 
IN operator, and the format of output of real values to a 
textfile. The changes involved are definitely improvements. 

The definition of Pascal should not be changed from that 
given in the draft in any essential respect. There are, 
however, some features which should be specified more 
exactly. 

Moreover, after the official approval of the standard by ISO, 
a project should be started in order to define "level 2 
Pascal", i.e. to standardize some extensions to the language 
described by the document being currently prepared. It is 
well known that there are several extensions to Pascal in 
existing implementations. Often the extensions serve similar 
purposes but differ in their syntax and/or details of 
semantics. Given that extensions are available and are used, 
portability of programs could be increased if the most common 
extensions were standardized. 

The project suggested would inevitably encounter serious 
problems because of the .varying needs of the users as well as 
the different opinions of language implementors and computer 
scientists. Anyhow, the Pascal language was designed for 
teaching - and is undoubtedly the best language for that 
purpose - but is being used for the construction of 
complicated "real-life" programs and systems as well. The 
true applications of Pascal require carefully selected and 
defined extensions to the language. 

Admittedly, Ada is an extension of Pascal, but in" roughly the 
same sense as Pascal is an extension of Algol 60, i.e. very 



far from being a pure extension. A fundamental differ^^ncp 
between Ada and Pascal is that Pascal can be learned in toto 
within reasonable time,- even by a person with no previous 
experience about computers, whereas Ada is "everything for 
everybody" which make; the language conceptually difficult 
and large in contents. 

There is no need to suggest what the "level 2 Pascal" would 
contain. Instead the problem is to limit the extensions to a 
conceptually clear repertoire which increases the expressive 
power of the language without substantially decreasing 
efficiency of implementation. In our opinion, the following 
extensions (possibly together with some minor extensions) 
would constitute such a repertoire: 

1. use of static expressions instead of constants. 

2. Some kind of module structure. 

3. Separate compilation of modules, together with the 
definition of the properties of the software support 
needed. 

4. Dynamic arrays, which could be added to the language 
simply by allowing the use of a parameter of a procedur*? 
or function in the same manner as constant identifiers i\ 
type definitions. 

5. Double-precision real numbers. 

6. The LOOP EXIT construct. 

7. OTHERS branch and/or subrange notation for case constant 
lists in CASE statement. 

8. Additional predefined procedures and functions for file 
operations (close, delete, append, etc.), including tools 
for control over input errors like invalid format of 
numeric data. 

9. Standardization of the feature that program parameters 
declared as array variables represent external random 
access files. 



1.3 CONCEPTS AND DENOTATIONS 

When describing a programming language, clear distinction 
should be made between an underlying concept (an abstract 
entity) like a variable, and its denotation like a variable 
denotation. The draft is incomplete in this respect. For 
variables, such distinction is made in most contexts; but for 
types not. Moreover, the production rule for variable 
d'enotation ("variable-access" in the draft) uses terms like 
"entire-variable"; a more adequate term would be 
"entire-variable-denotation" . 

Consider, for example, clause 6.4.3.5. It first specifies 
"file-type" by a production, i.e. defines the term 
"file-type" as one form of type denotation. However, the text 
then uses the term "file-type" as being something which can 
be denoted by a type-denoter . Such confusions could be 
avoided by the systematic- distinction mentioned. 



;l,4 the structuws of xanguage p^finjtion 



The <Jta£t uses the verb "shall", excessively , standard, by 
its very nature^ ^ays how things shall (or should) be? 
undiscr iminated UjS.e of "^shall" is redundant. 

Koreover, exaessive use of "shall" hides the fact that the 
different stat-ements in -the ;dr?ift starii^aird have varying 
logical sta^tus. Language definitions (excluding experimental 
formalized systems) in gteneral consist of (a) rules for 
context free syntax, :usu.aliy given in BNF form, (b) 
addirtiohai syntactic rules/ cfiven in prose, and (c) semantic 
;ruleis, given in prose and heing somewhat less exact than 
syntactic rules. The draft uses "shall" b.oth in class (b) and 
in class (c) rules. It would be ;npre natural tc restrict the 
use of "shall" to class (b.) rules, class (e) rules just 
stating wha-t IS the meaning af a language construct. 

In addition, there are t;he specifications for error 
conditions, with the word "error" used to designate what is 
commonly known as runtime error.. (A processor may of course 
be able to detect a runtime error d.uring compilation., in 
special cases.) In these specifications, "shall" is not 
necessarily strange but useless. 

Yet another group of statements in language definition 
consists of nominal def initions (if or auxiliary concepts) . In 
a sense, a language standard as such is, a nominal definition 
of a language. From the pead^r's point of view at least, it 
would be very useful to aeparate nominal definitions (in the 
strict sense) from the other contents of the standard. They 
neither describe the language nor set any requirements upo:i 
complying programs o^ pr po.essor S r but serve for the purpose 
of description and specifying requirements. 

Consequently, the lowest level clauses of the standard (i,e. 
clauses not containing any other clause) should be organ: zeo 
as follows. First .the relevant production rules are given (ir 
BNF) . Then the additional syntactic requirements arc 
specified, in prose, but exactly, using whatever a-jxil.-acy 
technical terms are needed. Next, the semantic rules a-? 
given, in prose, and this specification is sometimes 
unavoidably inexact (but uniquely interpretable by 
experienced benevolent readers). Finally, the error 
conditions, if any, are specified. 

Whether the suggested structuring i§ reflected by appropriate 
sub^titles, paragraphing, layout, or similar methods, is a 
matter o-f convenience. In most cases, paragraphing seem." lo 
be the most adequate method,. The first prose pe *••=■. 7 d';'^ 
(syntactic rules) may well use the word "shall", whilst th" 
others shpuld use "is". 

Nominal definitions should, if possible, be collected into 
separate clauses, and clearly distinguished as such, e.g. oy 
beginning them with "Definition." or "Convention.".. Then it 
would be unnecessary to use clumsy constructs in'Engli-jh; 
instead of "a shall be designated a.s b" one jnay specify "a is 
called b", "a is said to be b'' , or simply "a is b" . 



TO make the suggestions more concrete, here is a revised form 
of 6.. 5. 5 (with no changes to the cont,ents) : 

6.5.5 Buffer-variables. 

buffer-variable » file-variable . 
file-variable « variable^access . 

A f ij-e-variable shall be a variable-access that denotes a 
variable possessing a file-type. 

A buffer-variable denotes a variable associated with the 
variable denoted by the file-variable of the buf fer-vaxii-bie . 
A buf fer-variable associated with a textfile posse/^.?-? t » 
char-type; otherwise", a buffer-variable posse.>iie3 th-: 
component-type of the file-type possessed by '^l.-. 
file-variable of the buffer-variable. A reference or aco^s. 
to a buffer-variable conslbitutes a reference or ac-.-eiss, 
respectively, to the associated file-variable. 

Examples : 

input'' 

pooltapeii2A^ 

It is an error to alter the value of a file-variable f when a 
reference to the buffer-variable f^ exists. 

The revised form uses the terminology of the draft, and is 
not to be taken as a final sugge.stion but rather to 
illustrate the method of presentation. 

The term "implementation-defined" is defined (clause 3.2) too 
vaguely. In particular, may the corresponding definition (for 
an implementation) specify additional error conditions, 
restrictions or even changes to the specifications in the 

standard? 

Especially important problem arises from the fact that 
binding of program parameters of file type to external 
entities is " impiementation-def ined" . Does this imply that 
there must be some binding? If not,, it is possible to provide 
a processor which strictly conforms to the standard but .'. :. 
completely useless. Moreover, it is assumably intended that .i 
program parameter of type Text can be bound to a device li<?? 
terminal, line printer, or card reader. Now suppose that we 
bind a such a program* parameter , say f, to a terminal, writo 
to the file f, and then try to pip Reset(f) . strictly taking 
this shopld give us the opportunity to read back what we 
wppte. (Clause 6.6.5.2 implies that Reset (f) does not chango 
the sequence of components associated with the value of f, 
except that it may append an end-of-line component to it.) 
Although this is iraplementable (by making, say, a disk coj3.>' 
of 'everything written to f) it pragmatically makes no sensi. 
The problem is even clearer for a file bound to an unspoolod 
card reader, first opened by Reset and then re-openev") by 
Rewrite; since the pre-asser tion for Rewrite is True, tho 
operation should definitely be possible. One solution io oi! 
course to prevent the binding of a prpgram parameter oth»r 
•than Input or Output to a device; but such a restriction 
seems unacceptable and it probably is not the intention that 
the standa;:d would implicitly require it.. 



Consequently, one should either specify that the definition 
of an implementation-defined feature introduces modi ficat io-i.? 
to the language specification, or to remove any need Cor : i 
modifications. (The latter alternative is definitely boiLe', 
and would require changes to the specification of Reset a-.. 
Rewrite at least, probably also the specification of cea: 
arithmetic operations which should be specified to bo an 
error if the operation is not carried out with sufficient 
accuracy. ) 



1 . 5 TERMINOLOGY 

The following changes of terminology are suggested. They 
would be motivated by the terminology currently in use, or by 
simplicity, or by a clearer distinction between "things and 
names", i.e. between (abstract) entities and their 
denotation. 

"The y closest-containing an x" should be replaced by "th^: 
smallest y that contains an x** . ("Closest-containing" doe'; 
not correspond to normal rules of formation of words in 
English . ) 

"New-type", "new-ordinal-type", etc. should be replaced by 
"type-description", "ordinal-type-descr ipt.ion" , etc, , 

"ordinal-type" by " ordinal- type-denotation" (or -denoter) , 
and so on. A type-denotation is a language construct that 
denotes a type? a type is an abstract entity (and the wc-d 
"type" as such should be reserved for that purpose); and a 
type-description is any type-denotation which is not a 
type-identifier . 

Similar changes should be made to terminology relate? »-.o 
variables. "Variable-acces-s" should be replaced _ .r; 
"variable-denotation". The variable (as abstract enti-x/,^ 
associated with a file-variable should be cal]-. 
"buffer-variable"; it can be ^ denoted. ry 

buffer-variable-denotation of the form f but it need rot 
(for example, a formal parameter may denote a buf.^?- 
variable) . 

"Identified-variable" should be replaced^ by 

"referenced-variable" or " r ef erenced-variable-denotation . , as 
appropriate. 

The phrase "the type possessed by x" is strange and 
artificial. It should be replaced by "the type of x" . T*.: 
will be possible when "type" is restricted to refer to sn 
entity, not to a syntactic construct (because "of" applied to 
■ syntactic constructs has a specific technical meaning by 
clause 4) . 



There seems to be no good reason to use the attribute 
"required" instead of ^predeclared" or "predefined", except 
that it may shorten some specifications (sometimes "requ^-vl" 
should be replaced by "predeclared or predef in:J" ) . 
Admittedly the existence of e.g. the type intor-.-i: 
"required"; but the. potential existence of enumerate! l.:* 
is "required" as well. Moreover, the "required" :>f 
identifier Integer can appropriately be called "predeC • •'••^" , 
whereas the type denoted cannot adequately be C:>'<\-} 
"required" or "predefined". It is "introduced by lang.iage 
definition", but such a term would admittedly be clumsy. 



CHAPTER 2 
DETAILED CO.^IMENTS AND SUGGESTIONS 



These comments are organized according to. the structur>' o 
the draft. 

The relevant clauses of the draft are referred by Lhi?ir 
number only, so that these comments should be read tog-:*th; ; 
with the draft. 



2.1 LEXICAL TOKENS 

The statements "Identifiers may be of any length. All 
characters of an identifier shall be significant." arr 
redundant and should be made into a note. Howrv.-^', 
restricting the number of significant character^-. i • 
identifiers to, say, 10 would not decrease the expr e ■ i i v.^ 
power of Pascal, would allow compilers to be slightly mor'.* 
efficient, and would promote portability of programs (be-Mu-i.* 
in any case programs will be used in environments loc 
supporting infinite recognition length) . 

The statement "A directive shall occur only in a 
procedure-declaration or function-declaration." coul'.' 
misinterpreted so that, for instance, "forward" could not bo 
used as identifier (which is the case in it 
implementations) . A clarifying note should be added. 

Clause 6.1.5 states that "An unsigned-real shall denor...- i" 
decimal notation a value of real-type". The mean5>3 c ' 
"denote" in this context requires clarification, sincf. 
unsigned-real in general does not exactly correspond to any 
value of real-type (the internal representation of real 
numbers being what it usually is) . Moreover, it cannot be 
uniquely derived from 6.1.5 what a processor should do yit' 
an unsigned-real whose mathematical value is outside tiie 
implemented range. Consider le-lOOO (assuming a typical 
floating point representation in which no accu^'di..-? 
representation for it exists) ; should the processor reproron'.. 
the value as 0.0, or as the smallest positive real n -.i • 
representable, or should it give an error message? And .» ia^ 
about le+1000? 



The pseudo-production for string-character should be replace- : 
by a more adequate formulation, e.g. by the following: 
The syntax rule for string-character i 

implementation-defined and shall have the form 

string-character = al 6 a2 o ... o aN . 
where each of al , a2, aN is a terminal symbol denoting .\ 

single character. 



2.2 BLOCKS, SCOPE AND ACTIVATIONS 

The draft requires, for a change, that every declared ' -^b-?!. 
must be used. Admittedly it is good programming practifi'- nr-r 
to declare labels which are not used; but why s'-oj'- ' 
be treated differently from identifiers in thi s r '^sp- • ? 
processor may give warnings about unused identifier: -i ^ ' 
labels or it may not; but to specify such redun.lancy t- ^ 
violation of the" rules of language is questionable. 

A note should be appended to clause 6.2.2, saying that t:^. 
scope of an identifier shall not contain applied occur r»-nc.- 
of synonymous identifier (from outer scope), iC ':n- 
principle is to remain. However, the proposed scope • 
unnecessarily com.plicate compilers, and it is unlik?ly^ h; 
any standard can enforce such rules to be implemon^. • 
pascal processors. We strongly suggest that the definiti.-i c-- 
scope be revised back to the principle that the scope r,: :• 
from the def ining-point . It would hardly decrease ^^-i-^'-."^' 
security, and would be intuitively more understandable .'.^ 
the principle that the scope begins at a point preceding -zr.r- 
def ining-point. 

Clause 6.2.3.2 would be easier to understand if some not. 
were appended, e.g. a note stating (as in the first drif^' 
that each activation of a block introduces a collection o; 
distinct local variables. 

Clause 6.2.3.3 is extremely vague. Is the first stacr-'-' 
nominal definition of "within" relation between activdu m-. 
or does it prescribe where an activation can be d'.^ni.T t 
(by what?). The statement after the note uses tv- ^ 
"within" to denote a relation between occurrences of 1 o 
and identifiers, on one hand, and activations, on the c 
presumably the word "within" should in that contex* .-v 
understood in some intuitively evident sensej but in vhnt 
sense can an occurrence be withm an activation? ^.u. 
occurrence of an identifier primarily appears (textu:riv' 
within a block, and it obviously denotes some entity k .u. • 
belongs to some activation of that block; but the pro 'I'-t. 
remains: what is the corresponding activation? 



2.3 CONSTANT-DEFINITIONS 

The semantics of a sign in a constant, however obviou-. . 
should be explicitly specified. (Notice that such a sign Ir. 
not an operator, so that the semantic rules for unary + an.1 
are not applicable.) 



2 . 4 TYPE-DEFINITIONS 



2.4.1 General 

The stater^ent "The- required types shall be denoted '">y 
predefined type-identifiers ." is redundant. 



2.4.2 Simple-types 

The alternatives integer-type, Boolean-type, and char-tyt^*-* 
should be removed from the production for ordinal-type. They 
are redundant (being special cases of 

ordinal-type-idenjtif ier) , there are no productions for ! -vr::, 
and the terms are used to refer to the abstract type-en t i '.. i i- 
(instead of identifiers) in the sequel. 

The production 

real-type = type-identifier . 
should be added. 

The specification of the required numerical types would be 
clarified by referring to "the mathematical set of whole 
numbers" instead of just "whole numbers" and similarly ^or 
real numbers. 

Since the specification of integer-type in 6.4.2.2 mighl 'v 
interpreted as excluding the possibility of existence oL 
values of that type outside the interval -Maxint . .Max I. . 
is suggested that the sentence beginning with "The v i." . 

shall be a subset of the whole numbers " be trun^rai--- c 

that part cited; the denotation of values of in tege r-t \ >, 
signed-integers is sufficiently described by clauses 6.1.1/ 
and 6.3, provided that the latter is extended by a 
description of the semantics of a sign, as suggested earlier 
in these comments. 

The rules for subrange-types (in 6.4.2.4) are inexact and 
given in a confusing order (syntactic requirements I'-i i^ 
intermixed with semantic specifications). For exam -l*: , 

starting the description by "The definition of a type 

may suggest that subrange type denotations would only be 
allowed in type definitions, and leaves unspecified what ' ."^ 
definition of a type. 



2.4.3 Structured-types 

The specification of the effect of PACKED should be in-'.- 
clearer. The phrase "should be economised" can be in terpr to.? 
so* that PACKED is a suggestion only, and the processor 
choose not to apply any effective packing even if it wou'" o- 
possible, or a processor may ignore PACKED entirely. Thi.'^ ' ■ 
assumably the intended interpretation; the next par agr -i,:r. , 
however, refers to the representation of a type (values of a 
type) in data storage as being "packed". Evidently th?- i:? 
some- confusion, because nothing prevents the procer-.or •' •• jin 
representing a structured type not designated p;».ckf>d i'l p. 
form which is packed (in the sense that minima} .«?tor cj. 
used) . 



Consequently, clause 6.4.3.1 should be modified as fol ' v.-t 
^'irst, the only statement that is strictly relatf- • 
language definition is made: "The occurrence of the *- ik--" 
packed in a new-structured-type shall designate the .^'..v 
denoted thereby as packed." Then the following is stated '-r 
note: "The designation of a structured type as pack .'0 lo'-.v 
not designate any component of the type as packed." Thf i 
note about the logical effect is given; this, note may rp. ' 
the note in the draft. Finally, a third note (whic- i- 
practically ver.y important but logically irrelevant) j^: -^u"" • 
be given, e.g. as follows: "On many processors, I vr 
designation of a structured-type as packed may caus. 
representation of values of the type to require "loss • • i 
storage than otherwise would be the case; on the other :• i, 
it may cause operations on, or accesses to componenL-n ■>• , 
values of the type to be less efficient in terms of spaco, or 
time, or both." 

In 6.4.3.2, as well as in 6.5.3.2 and 6.6.3.7, cer*. -.'jn. 
syntactic constructs are defined to be "equivalent". Thf- 
precise meaning of such definition is left unspecified. ■•7i':r-. 
"equivalent" presumably means is roughly what is 
"identical" according to Leibniz' definition of Icip": — / 
("EadeiR sunt qui inter sibi salva veritate sul • ' 
possunt"). Thus, a definition (convention) should be 
stating that when two syntactic constructs are defin.i^.i ^ 
equivalent, this means that either of the two construct-:*- i ♦ 
be replaced by the other without affecting the correctn^- .• .- ■ 
meaning of a program, and that any rule given for elfcht-j:- 
construct is applicable to the other as well. 

A note should be given in 6.4.3.3, stating that for a variant 
part without a tag-field, • the selector of the variant part 
does not necessarily have a physical correspondence in the 
representation of the record type. 

Clause 6.4.3.3 allows empty field-lists which, implies that vin 
empty record is allowed. However, the question arises whothc-r 
a variable of an empty record type is initialized or not; on 
one hand each variable is uninitialized when it comes fj 
existence; on the other hand, a record is initialized '.-.'hen 
all of its fields are initialized, which means that an r-.- pty 
record would always be initialized. Since empty records are 
useless, a minor change of definition would remove this 
theoretical but irritating problem: remove the outermost 
brackets from the production for field-list, enclose the 
symbol field-list into brackets in • the production for 
variant, and add (into the text) the requirement that for a 
field-list with no fixed-part, at least one variant of the 
variant-part shall contain a . field-list. 

The draft does not specify any restrictions on the use of 
ordinal types as the base-type of a Set-type. This 
effectively means that implementation of sets will be rather 
inefficient, which causes set types to lose a lot of their 
usefulness. (So this change to the language is an operation 
which may succeed but the patient may die.) The restriction;^, 
as specified in the first draft, should be restored. 



2.5 DECLARATIONS AND DENOTATIONS OF VARIABLES 



Clause 6.5.3.2 does not specify the order in which thP 
indices of an indexed variable are evaluated; neither does it 
state that the order is implementation-dependent. Analogously 
with e.g. 6.7.2.1, it should be specified that the ord-r of 
evaluating the index-expressions in"^ an indextd-^ariabl^ is 
implementation-dependent. o.^ x& 

The production 

field-designator-identifier « identifier . 
should be included into clause 6.5.3.3. 



2.6 PROCEDURE AND FUNCTION DECLARATJC^.o 

Clause 6.6.3.1 specifies that with each formal value or 
variable parameter there is an associated variabl^^ Th-s 
specification is somewhat obscure because of the pre-rV- 

the^ article "the" (" def ining-point as the assov .at ■ 

variable-Identifier ") . similar comment applior. c; 

procedural and functional parameters. The use of "the" \30Gin ' 
to suggest that the existence of such an associated oPtit'/ 
has been previously postulated, which is not the case. 

Clause 6.6.3 does not specify any restrictions on the allowed 
types of a formal value parameter. Clause 6.6.3.2 specifies 
that the actual parameter must be assignment-compatible with 
the type possessed by the formal parameter. This means that 
It is legal to declare a procedure with a value parameter oF 
a file type but illegal to call such a procedure. This is 
somewhat strange; in general, language definition should not 
formally allow constructs which are useless. The followinq is 
suggested: ^ 

1. Add the following definition to clause 6.4.3.5, befor" 
the first paragraph of the very text: "A type is said to 
have a file component if it is a file type, or an arrav 
type whose component type has a file component, o>' a 
record type such that at least one of its fields is or" a 
type tnat has a file component." Change the paragr ioh 
mentioned to read as follows: "The type-denoter of 'a 
file-type shall not denote a type that has a file 
component." 

2. Change statement. (a) of 6.4.6 to read as follows: "(a) Tl 
and T2 are the same type which does not have a file 
component. " 

3. Add the following sentence to 6.6.3.2: "The tvoe of a 
formal parameter shall not have a file component." 



By 6.6.3.3, "An actuaj. variable parameter shall not dene*-.' ^ 
component of a variable that possesses a type th^^ v- 
designated packed." However, there is some doubt about^ th*:- 
relation of componentship. For clarification, the followini 
note should be added: The relation of componentship is n'o« 
transitive; that is, if a is a component of b and b is a 
component of c, then a is not a* component of c. 



In 6.6.3.7, it is said that the actual parametei* 
corresponding to a conformant arr.ay schema "shall be. eithr»r li 
variable access or ' an expression that is not a factor that is 
not a variable-access". This is not very explicit, atv: it 
seems that the contents of that specification is not what is 
intended; probably the second "npt" should be removed? Of 
course/ any variable-access is an expression' that is not a 
factor that' is not a variable-access, so the subsequent ruins 
are ambiguous. What is effectively meant is probably that 
such an actual parameter shall be either a variable or \n 
expression that is either a string constant (possibly [k 
parentheses) or a variable enclosed in parentheses. 

On the other hand, the differences' between the first ore," 
and the second draft in the specification o. 
conf ormant-array-schemas clearly show that the authors of the 
second draft wish to allow conf ormant-array-schemas as \al\'^ 
parameters. We have no strong opinion about such r.n 
extension. However, if accepted, the extension should be made 
in a less confusing way. In general, value and variable 
parameters are distinguished by the absence or presence of 
the token VAR in a parameter-specification. We can see no 
reason why this method should not be used tor 
conf ormant-array-schemas , too. 

The note in clause 6.6.4.1 should not be a note but a part of 
the very specification of the language. Moreover, it leaves 
undefined what rules, if any, given for user-decJ n i ed 
procedures and functions are applicable to requir-?d 
procedures and functions. This incompleteness is particularly 
important to the semantics of Write, Writeln, Read, Readln, 
Pack, and Unpack. 

Clause 6.6.5.2 specifies the semantic of Read and Write in 
terms of an expansion into more primitive statements (c£, 
also 6.9 for similar expansions). Now if Read(f,a,b) shalT be 
equivalent to BEGIN Read(f,a); Read(f,b) END we have to aj<: ' 

1. shall the variable f be evaluated several times 

2. shall such evaluation be affected by the effects of the 
previous operations caused by the statement (consider 
Read (f AiA, i , j ) ) 

Obviously it is intended that access to the file variable is 
established as the first operation in. the execution o£ tb«- 
■ procedures mentioned; this should be specified. 

Clause 6.6.5.4 defines the transfer procedures Pack and 
Unpack as "macros" * whose calls must be equivalent to th* 
given expansions. However, it makes no sense to interprft 
this literally because it would imply that the parameters are 
name parameters, quite contrary to the nature of the Pascal 
language. (Literally, 6.6.5.4 would imply that if in, ray, 
Pack(a,i,z), a is an indexed variable (of an array type, c£ 
course) , its indices should be evaluated N times where ii- 
the number of components of z. Consider the (admittCi13^ 
theoretical!) possibility that the evaluations of • a a:;d - 
a'ffect each other!) - Thus it should be specified that t>. • 
parameters of Pack and Unpack shall be evaluated once orly, 
in an implementation-dependent order. 



2.7 EXPRESSIONS 



Clause 6.7.1 says that "An expression shall denote a value 

and clause 6.7.2.1 speaks of "evaluation" of 

expression. However, it is not defined what is the value .^i' 
an expression, or what constitutes the evaluation ■•>: 
expression. It would not be very difficult to si'ppl.. 
sufficiently precise definitions. 

According to clause 6.7.2.2, "The results of the re-.:, 
arithmetic operators and functions shall be approximations t:; 
the corresponding mathematical results. The accuracy of this 
approximation shall be implementation-defined." Such a 
specification is definitely an improvement but is 
insufficient. For what is an approximation? Suppose that we 
have a floating point system where the range of absoluLi? 
values of representable numbers is roughly le-3 8 to le+J8, 
and consider the operation of squaring the number le-30. i? 
0.0 an approximation to the result? Most mathematicians would 
say no. And what about squaring le+30? Notice that who I. ? r 
commonly known as floating point overflow or underflow .'^ha'. ' 
not be an error according to the draft. Assumably a proce.is .v- 
may give a runtime warning; but it must also proceed 
some "approximation" to the result. Notice also that cl-iu^c 
6.6.6.2 specifies that sqr (x) is an error if the square. of x 
does not exist; this can be interpreted so that underflow ci 
•overflow in the calculation of sqr (x) for real x would be an 
error; why should sqr be exceptional in this respect? 

It should be specified that the order of evaluation of th=^ 
expressions of the member-designators of a set constructor is 
implementation-dependent. C-urrently no order is specified, 
which should probably be interpreted so that the order ii^ 
implementation-dependent, but this should be stated 
explicitly. 



2 . 8 STATEMENTS 

The requirement (in 6.8.3.9) that "The statement o" 

f or-statement shall not contain an assigning-r ef erence to 

the control-variable of the f or-statement . " is understanr' 
from the security point of view. However, it req'. v 
complication of processors which would not be o ther •; vi?.- 
necessary (at least partial cross-reference information .: 
be gathered). This means extra costs, the benefits l>---invi 
questionable. These comments of. course on-ly apply to che»'i i 
against assigning references in procedures and fund ioiv 
invoked within a for-statement . One solution would bo x > 
require that the variable used as a control variable 
not be used outside that statement part in which I- • 
corresponding for-statement occurs. This would ba^ 
decrease the expressive power of Pascal. It is moreover 'Ov. • 
programming practise to reserve the control variables fci 
that purpose only. Such a restriction would allow the rule 
mentioned to be formulated in a manner which can be 
implemented with no significant extra costs. Notice that 
speaking of implementation in this context refers to inhei»-->nt 
problems of implementing the requirement of the draft, not to 
any particular implementation. 



2.9 INPUT AND OUTPUT 



The effect of read(f,v) when f is a textfile and v is -jf 
integer or real type is incompletely specified in claus:e 
6.9.2. It is said that it causes "reading from f a sequence 
of characters"/ and assumably reading involves the sa:ne 
operation as get. However, the details are unspecified. The 
error condition descriptions use the notion of "the rest of: 
the sequence", but it is left undefined what "the sequoncfc" 

is; a related rule ("Reading shall cease ") is given, but 

it is obscure. For instance, if the characters "1", "E", aa'? 
"X" are^ encountered, in that order, when reading a re.-sl 
number, what happens? Most existing runtime systems repor' i 
format error, but the specification of the draff would . pcm 
to imply that the input should be accepted, "1" being the 
longest sequence available that forms a signed-number . It ir, 
not only difficult to implement the lookahead required; .such 
lookahead would be quite contrary to the fundamental ideas of 
file handling in Pascal. 

It is said, in 6.9.2 (b) , that ""It shall be an error if the 

rest of the sequence does not form a signed-number according 
to the syntax of 6.1.5.". This purely syntactic approach 
gives no answer to the question how underflow or overflow 
should be treated. 

The definitions (c) and (d) in clause 6.9.2 should be given 
by appropriate equivalent program fragments or other uniquely 
interpretable methods. 



2.10 PROGRAMS 

The note in clause 6,10 is very . obscure. What are the 
properties of a PascaJ. program? 

The pragmatic meaning of sample program t6p6p3p3d2revised arr 
test program should be enlightened. Moreover, the program is 
related to earlier versions of draft standards (the program 
is not related to clause 6.6.3.3 as one would expect), arr* 
should be accordingly updated. 



2.11 HARDWARE REPRESENTATION 

Commfent delimiters should be required to be matching, so that 
comment beginning with " (*" is only closed by "*)" and 
comment beginning with "a" i^ only closed by "&". In fact, 
clause 6,1.8 should be rewritten in this respect, so that 
there would be two different forms of comments. The character 
"ci" (as well as "a") has been replaced by a national letter 
in several modifications of international character coder 



2.12 TYPOGRAPHIC ERRORS AND STYLISTIC MATTERS 



The table of contents does not correspond to the titles in 
the text (e.g. for clauses 6.1 and 6.2). 

Clause 3.4 should say "accepts a program" instead of "accepts 
the program", i.e. accepts any program (subject to 1.2 (a)). 

-o 

The specification of char-type in 6.4.2.2 would be better ^ 
formulated if the beginning of the second statement would <^ 
read as "The values shall be the enumeration of an ? 
implementation-defined set of characters". Similar comment ^ 
applies to the pseudo-production for "string-character" in m 
6.1.7. ^ 

In 6.2.2.9, the word "new-pointer- types" should appear ir 

singular, because it is preceded by "any". 1^ 

In the final note in clause 6.4.3.2, the comma following the 
word "which" is ungrammatical . (Possibly, it should preced«^- 
the "which".) 

In 6.4:3.5, the paragraph beginning with "Let f.L and f.R 

each be a single value " uses the word "single" 

redundantly in two occurrences. 

In 6.4.4, the comma after the word "them" in the secon;3 
statement is ungrammatical. 

The abbreviated notation specified in 6.5.3.2 and 6-6.3-7 ^ 
described by saying that "a single comma" or "a S/. -g\ : ^ 
semicolon" replaces a certain syntactic construct. The ..•or.: r— 
"single" in these contexts is redundant. 

♦ I—- 
In 6.6.3.6 (e) (1), the word " index-type-speci f ica tion'' is S 
misspelled as " index-type-specifiecation" . ^ 

In 6.6-5.3, the second statement of the specification of thu 
second form of new contains the misspelling "possesed" of 
"possessed". 

In 6.9.4.5.1, the specification of the condition under whir'i 
the sign character is involves the condition (eWr it!-'-* 

0) . However, it seems to be so that (e<0) imp" • • 
(eWritten>0) so that the latter can be omitted. Probably i^e 
redundancy results from an analogy with 6.9.4.5.2. (For f Ixc/J 
point representation the condition (e<0) and (eWritten>0) 
does not contain redundancy, of course.) 
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ATTACHMENT E 



COMMENTS PROM THE FRENCH MEMBER BODY 
ON ISO/tc 97/sc 5 N 595 
SECOND DP 7185 - SPECIFICATION FOR 
COMPUTER PR0GRAMI4ING LANGUAGE PASCAL 



GENERAL 



The French committee voted positively ahout this second draft proposal, one 
of its main motivations being that the standardization of PASCAL will he useful 
only if it is completed very soon. As a further way to speed up the remaining 
part of the standardization process, the French member body strongly suggests 
that the nezt meeting of VG 4, whose main purpose will be to revise and incor- 
porate if possible those improvements suggested during the vote, do not wait 
until the next meeting of SC 5 in London, but is convened before summer. 
The French member body officially offers to organize such a meeting in NICE, 
France, in June or July of 1981. This should allow the completion of the standard 
to be done in the present year. 

The following comments are devided in two parts : technical comments, which deal 
with the language PASCAL as described in the second DP 7185, and editorial comments, 
which deal with the description itself. Comments considered especially important 
by the French member body are emphasized w? th an asterisk. 



COMMENTS 

* Character f e^>_£pe£i^l_£y5^ols^_reference_langu^ 

The French committee tried several times, but with no success, to obtain the 
specification in Standard Pascal of a required character set, and to obtain a 
clear separation between the description of the reference language and its 
various hardware representations. The current state of the draft proposal shows 
that these proposals were not so bad, since, while the printing quality and the 
character set of the descriptions of Pascal are quietly worsening from one version 
to the next, they become at the same time more and more similar to the current ISO 
standard character set. The last evidence of this progressive modification is the 
replacement of the character " f the* only remaining one that was not in the ISO 
set, by the character "^»'. Although these modifications result only from successive 
changes in the printing devices used for the successive descriptions, some benefit 
can be got. Hopefully, the final version of the standard description will not use 
a printer with only the 48 character set of Fortran ! 

The main concern of the French committee is that the lexical description of Pascal 
does not prevent the use of good printing devices with their full range of capabi- 
lities, i.e. that Pascal programs printed with boldface keyboards, italics identi- 
fiers and not-too-offending operators (for exemple, in both ¥irth's books published 
by Prihtice-Hall) are legal Pascal programs. 



This does not deal only with books, after all, since the time when phototypesetters 
or printing devides of an equivalent quality will be usable for ordinary computer 
output is probably not so far. 

Although a clear distinction between the reference language and its hardware repre- 
sentations would have been considered by the French committee more appropriate for 
such a purpose, the current draft allows almost ' completely what we need, in a 
different way. Since the representation of letters is considered insignificant, the 
only remaining problem is with special symbols . Alternative representations were 
provided for implementations which lack some good quality characters, like square 
brackets or braces. In th'e present draft, an alternative is provided for implemen- 
tations which have a better character than "^"^ i.e. the up arrow. ¥e propose to 
prusue in such a direction, and to provide good alternatives for unsatisfying special 
symbols. No implementation is required to provide these alternatives if they are not 
available in its character set, but a program which uses them is legal. Our proposal 
of course, does not include bad representations for existing good symbols, made 
only for using available characters, like "&" for "and", for example, or worse, 
" # " for »^ " . 

Proposal : table 6, page 68 

Add the following alternative symbols, which appear in the order of decreasing 
importance : 

reference <'> and or not 

alternative ^ ^ v — i 



* 2---^2£5§^^ array parameters 

The French committee tried to compare the four successive variants of the proposal 
that were done in the first DP 7185, in ¥G 4 documents N 5 and N 9, and in the 
current DP. The main critic we made about the current state of the proposal is that 
a feature added for a very precise purpose (i.e. to allow character string constants 
as conformant array parameters) is now used for a couple tely different thing, remi- 
niscent of PL/i (i.e. simulating value parameters with dummy variables). 
Vhat is worse, the first intended purpose is not completely achieved, since a formal 
conformant array parameter cannot be a string variable, which greatly weakens the 
advantages provided by the feature. Several possible solutions were considered. 
The proposal we made seems to have only very simple consequences on both the descrip- 
tion of the language and its implementation, it needs no modification to the level 
0 conformity, and its has interesting consequences on most uses of conformant array 
parameters. 



Proposal '1 : Section 6.6.3.7i pages 35 to 37 

Come back to the wording of ¥G 4 N 9j or something equivalent which uses an auxi- 
liary variable only when the actuel parameter is a string constant, and moreover 
which does not force any implementation of the feature. 

Proposal 2 t Sections 6.4.3.2, 6.6.3.7 and 6.6.3.8 

In Section 6.6.3.7, allow the lower bound of an index-type-specification to be 
a constant of the suitable type, in which case the corresponding actual parameter 
must have an index type with the same lower bound. 



Conformant array parameters with a constant lower index "bound would pro"ba"bly "be 
the great majority, and they can "be implemented more efficiently. Moreover, in 
Section 6.4.3.2, extend the definition of a string type to include the case of a 
packed conformant array of characters with a constant lower hound of 1 . Thus the 
formal parameter is a string, comparison operators can be used as well as the 
procedure write, and it should only he stated that it is an error yhen upper bounds 
differ in an assignment involving such "conformant strings". 

Of course, the two preceeding proposals should he carefully worded, and all conse- 
quences on the full draff taken care of. This could he done for the next meeting 
of ¥G 4. 



Recursive type definiti o ns 

On page 12, Section 6.4-1, the last sentence of the paragraph that follows the syntax 
makes an exception to a general rule, especially for allowing the use of a type- 
identifier in a pointer-type, while it is not entirely defined, as in the following 
example : 

type T1 = record . . . x : tTI ; ... end ; 

Of course, this is not necessary, since the type tTl may he defined ans named before, 
an probably this definition is needed anyway for other purposes, because of the strict 
compatibility rules. What is worse, this exception legali25es some absurd type defi- 
nitions, as in the following example : 

type T2 = array O..IOO] of tT2 j 

T3 = tT3 ■; 

Proposal : Section 6.4.1» page 12 

Remove the first half of the last sentence .of the second paragraph, which thus 

becomes : 

"The type-denoter shall not contain an applied occurrence of -the identifier in 
the type-definition" . 

The_required_type_integer 

On page 48, Section 6.7.2.2, the first paragraph implies that there may exist some 
values of the integer- type that are not in the closed interval -maxint. .+maxint. ^ 
This seems useless. On the contrary, on machines using two's-complement arithmetic, 
the negative number with the largest absolute value could be used as an "undefined 
value, extremely useful for checking that variables are initialized. 

Proposal : Section 6. 7. 2. 2, page 48 

Reword the first paragraph so that the integer-type is exactly the interval -maxint.. 
+maxint . 



EDITORIAL COMMENTS 



- page 2, 1 .2 (a) 

Add the sentence and the actions to be taken when the corresponding limits are 
exceeded" . 

This suggestion was triggered by the constatation that nothing was said about what 
happens when the procedure new finds no more available space. 

- page 7, 6.1 .5 

Kothing- is said about the meaning of the period and the digit-sequence that follows 
it, in an unsigned-real. A possible solution would be to replace "digit-sequence" 
with "fractional-part", defined elsewhere as a digit-sequence. 

- page 10, 6.2.3 

This whole section is very difficult to understand. A possible solution would be 
to use a simple stack implementation model, not compelling for implementators, but 
much clearer. 

- page 11, 6.3 

This is the first occurrence of a systematic principle used in the whole standard, 
i.e. identifiers are always quelified in syntax rules, except for their defining- 
point. This is pretty good, but a note should explain it, for example, at the end 
of Section 6.2, or in Section 4. 

- pages 15, 18, 19 

Examples use type identifiers that are defined only on page 22 (colour, vector) 
or not defined at all (string, angle). Something would be done. 

- pages 33, 34 

Boring repetitions occur every time something is saif about procedures and 
functions. By defining the term "subprogram", and by specifying a uniform subs- 
titution with either "procedure" or "function", it should be easy to simplify and 
shorten the second paragraph of page 33 1 the last two paragraphs of the same page, 
and Sections 6.6.3.4 and 6.6.3.5 on page 34. 

- page 34, 6.6.3.3 

Since the types possessed by the actual-parameters are the same as that denoted 
by the type-identifier, they must be identical. The second sentence of Section 
6.6,3.3 is consequently useless. 

- page 35, 6.6,3.6 

By replacing in (a) the two occurrences of "value" with "value (resp. variable)", 
it is possible to entirely omit (b). 

- page 36, 6.6.3-7 

A note should be insered before the last paragraph of page 36, explaining that 
bound-identifiers are neither constants nor variables. 



page T7', 6.6.3.7 



The first sentence of the second paragraph is impossiljle to understand, and 
prohably -wrong. The fourth paragraph is extremely difficult to understand, and 
should he either vorded differently or illustrated with an example, or hoth. 
In the third note of the page, "anonymous" should he replaced -with ''auxiliary", 
for uniformity. 

page 45 > 6.6.6.4 

The descriptions of succ and pred differ only hy one- vord ("less" instead of 
"greater"). A simplification in the same vay as page 55 j 6.6.5.6 should he possible. 

page 47, D.-7.2.2 

The last three paragraphs of the page begin -with a sentence stating that a term is 
an error if something occurs. Given the definition of an error, it should be better 
to state that it is an error if y = 0 in a term of the form x/y, etc. 

page 50, 6.7.5 

For the sake of uniformity with Section 6.8.2.5, the second sentence should end 

■with "... activation of the block of the function-block associated with the fujaction- 

identifier of the function-designator". 

page 52,. 6.8.2.4 

The wording is extremely unclear, especially in (b). ¥hat are "these exceptions" ? 
page 55, 6.8.5.5 

By adding ", otherwise it shall be an error" at the end of the first paragraph, 
the second one can be omitted., 

page 55, 6.8.5.9 

Nothing is said about the assignment-compatibility of the initial-value, 
page 5.9, 6.9.1 

It seems that only textfiles occurring as program-parameters could be used at all. 
This relates to nothing elsewhere, and should be omitted. 

page 68, 6.1 .1 

The last part of note 2, dealing with the possibility of national variants, disap- 
peared during the summer. Vhy ? * 

page 67 

The chosen example cannot be considered a significant demonstration of the capabili- 
ties of Pascal. A better example could be found in one of the numerous textbooks 
about the language. 

Appendices 

Syntax diagrams are recognized as an excellent means for syntactic descriptions, 
especially for Pascal. They should be included in an additional appendix. 



ATTACHMENT F 

1981-03-02 German Comments on Second DP 7185 Page 1 

Part I. Technical reasons 

1 . Call-by value for conformant array parameters 

We do not approve that the call-by-value of conformant array 
parameters is specified by enclosing the actual para- 
meters in parentheses. In Pascal ^ the parameter access method 
is always specified with the formal parameters . There 
should be no exception for conformant array parameters . 

2. Use of "denote" 

The use of "denote" in Second DP 7185 is not consistent. See 
the accompanying notes "German concerns on the use of 'denote'". 

Part II, Editorial comments 

O. INTRODUCTION 

Delete this heading and include the text as new paragraph 1.3 . 
4. DEFINITIONAL CONVENTIONS^ Table 1 

Delete the line " > shall have as an alternative definition" . 
5.1 Processors (h) and (i) 

Replace "specified for errors" bjt "specified for violations". 
6.1 . 5 . Numbers 

Change the sequence of the syntax to run from signed-number to 
digit-sequence (top-down), in accordance with usage in other places 
of the Second DP 7185. 

6.2.3.2 (d) and (e) 

Formal parameters are associated to the block , not to the 
identifier (see 6.6.1). Change, therefore, the wording as foolows: 
(d) for each procedure-identifier local to the block, a procedure 
with, the procedure-block corresponding to the procedure-identi= 
fier, and the formal parameters of that procedure-block; and 
Xe) for each function-identifier local to the block, a function . 
with the function-block corresponding to, and the type posses- 
sed by, the function-identifier, and the formal parameters 
of that function-block. 



6.4.2.2 integer-type 

Include after "see also 6.7.2) the following text taken from 
6.7.2,2: "The required constant-identifier maxint shall denote 
an implementation-defined value Of integer-type. All integral 
values in the closed interval from -maxint to +maxint shall be 
values of the integer-type . " 

6.4.1 General . Second paragraph . 

Replace "as the domain-type" by "in the domain-type". 
6.4.1 General . Third paragraph . 

Delete the sentece "The required types shall be denoted by 
predefined type-identifiers (see 6.4.2.2 and 6.4.3.5)." 

6.4.2.2 char-type 

Insert after "without graphic representations" the following 
text " the others denoted as specified in 6.1.7 by the 
character-denoter" . 

6.4.2.3 Enumerated types. 

Delete "as their identifiers occur . 
add after "from zero." the following 
order preserving." 

6.4.3.1 General . 

Change the sequence of the syntax to run from new-structured- type 
to structured- type (top-down) . 

6.4.3.2 Array- types. Next to last paragraph. 

Insert after "a smallest value of 1" the following: "and a 
largest value of greater than 1 " . This is a clarification for 
the use of string types. 

6.4.3.2 Array-types . Last note .. 

Delete comma after "which" . 



. . enumerated-type " and 
: "The mapping shall be 



6.4.3.4 Set-types , 

Replace "of its base-type" in the first sentence by "of the 
base-type of the set-type". 

Replace "an unpacked set designated" in the last paragraph 
by "an unpacked set type designated". 

6.4.3.5 File-types. Last four paragraphs. 

Replace "a sequence XA/S(e), where x is" by "a sequence cs/vS (e) , 
where cs is" . 

Replace "If x is a line then no component of x other than x.last" 
by "If 1 is a line, then no component of 1 other than l.last". 
Replace "A line-sequence, z, shall be either the empty sequence 
or the sequence XAy where x is a line and y is a line-sequence" 
by "A line-sequence Is shall be either the empty sequence or the 
sequence I'vls' where 1 is a line and Is' is a line-sequence" 
Replace in (b) the text "shall be xvy where x is a 
line-sequence and y is a sequence of components" by "shall 
be Is/vcs where Is is a line-sequence and cs is a sequence 
of components " . 

In the NOTE following (b) replace y by cs in two places. 
6.4.7 Example 

In NOTES 2. replace "to have been declared" by "to have been 
defined" . 

6.6.1 Procedure-declarations. Third paragraph. 

Replace "the the procedure-declaration" by "the 
procedure-declaration" . 

6.6.3.6 Parameter list congruity . 

In (e) (1) replace "index-type-specif iecation" by 
"index-type-specification". 

6.6.3.7 Conformant array parameters . 

We propose to use the syntax as stated in "Notes on US concerns". 



6.6.5.2 File handling procedures. First paragraph. 

Move the clause, "and similatrly for fO^ and f^" to the end of 
the sentence . 

6.6.5.3 Dynamic allocation procedures . NOTE . 
Replace "see 6.8.2.2" by "see 6.8.2.2 and 6.6.3.2" . 

6.7.2.2 Arithmetic operators . 

The paragraph after the NOTE shall read as follows : 
"Any monadic operation performed on an integer value in the 
interval -maxin't. .+maxint shall be correctly performed according 
to hte mathematical rules for integer arithmetic. Any dyadic 
integer operation on two integer values in this same interval 
shall be correctly performed according to the mathematical 
rules for integer arithmetic, provided that the result is also 
in- this interval. Any relational operation on two integer values 
in this same interval shall be correctly performed according to 
the mathematical rules for integer arithmetic . " 
(Note that the other parts of this paragraph have been shifted 
to 6.4.2.2.) 

6.7.2.4 Set operators. Table 4. 

Insert after "a canonical set-of-T type" the following: "^ee 6.7.1)" 

6.7.2.5 Relational operators . Table 5 . 

Delete "(see 6.7.1)" after "a canonical set-of-T type". 

In the fourth paragraph after Table 5, replace "Where u and v 
denote simple-expressions" by "Where u and v denote operands". 

6.8.1 General . 

Replace "A label occurring in a statement" by "A label, if any, 
of a statement" . 

6.8.2.2 Assignment-statements. 

Delete the last paragraph "The state of a variable . . . possess 
a structured-type. " Insert this text under 3. DEFINITIONS as 
3 . 5 undefined . and 3 . 6 totally-undefined . 



6.8.2.3 Procedure-statements. First paragraphs 
In the text "which is list of" insert an "a" after "which is". 

6.8.3.5 Case-statements. 

Delete last sentence of the first paragraph "One of the 
to the case-statement." 

6.8.3.9 For-statement . 

Replace "The value of the final-value shall be assignment-com= 
patible with the control-variable" by "The value of the 
final-value shall be assignment-compatible with the type 
possessed by the control-variable" . 

6.8.3.10 With-statements . 

Replace "as the only record-variable" by "as single 
record-variable". 

In the Example replace "shall be equivalent to" by "shall 
"has the same effect on the variable date as" 

6.9.2 The procedure read. 

(c) Delete the clause "the longest sequence available that forms" 
Change the sequence of the last sentences. 

(d) same as section (c) . 

6.9.4.1 Multiple parameters . 

Delete the heading; preserve the text as part of 6.9.4. 

6.9.4.2 Write-parameters . 
Change to 6.9.4.1. 

6. -10 Programs. First paragraph. 

Replace "Each program parameter shall be declared" by "Each 
program parameter except the identifiers input and output, if 
occurring, shall be declared". 

Second example: Replace "t6p6p3p3d2revised" by "t6p6p3p4d2revised 



German concerns on the use of "denote" 



In the use of the word 'denote', we realize the insight 
that there exists a sharp difference between the 'thing' 
meant by a certain piece of program text, and the program 
text itself. All kinds of syntactic constructs never are 
those mysterious Pascal, things, but only denote them. 

NOTE: This distinction may be found in some formal language 
definition techniques, especially the denotational semantics 
(see Gordon, Stoy, Tennent, B j orner/Jones) . 

We fully agree with an approach allowing us to treat the 
Pascal objects without need to refer to some syntactic 
instances, and we feel it the only way to succeed in drafting 

an unambiguous and yet understandable standard. 

Unfortunately, hov/ever, the promising approach has not been 
carried throught the whole draft, what lack, on the one hand, 
makes it even more ambiguous than former, not formally based, 
drafts, and on the other hand, at some points totally unclear. 

As an example for the latter conjecture look at 6.6,3.7 of 
1?9 . There is stated on p. IE, line 8f: "...the formal parameters 
shall possess an array-type and in the NOTE on the same 

page: "The type of the formal parameter cannot be a string- 
type (see 6.4.3.2) because it is not denoted by an ar ray- type. " 

For the initiated, the v/ord "denoted" in the note makes clear 
that the latter "array-type" means a piece of text derivable 
from the syntactic non-terminal array-type (p.l5 of K4), v;hile 
the former means a semantic entity, a property of a variable 
structured as an array. Is every reader of the standard initiated? 

The following lines list those places in M4/N9, where we 
found errors in the two drafts related to the "denote "- 
distinction betv/een syntactical and semantical entities. 
V7e do not claim for completeness! 

- 6.4.2.1: simple Types General: \-je are not able to derive the 
real-type (integer-type, boolean- type, char- type) from simple-type, 
but only the denoting identifiers. 

simple-type = ordinal-type I real- type-identifier 
ordinal-type = nev;-or dinal-type I integer-type-identifier I 

Boolean-type-identifier I char- type-identifier 

- 6.4.3.2 Array- types: the second to sixth occurence of the 
v7ord "array-type" in the section address the synctactic 
entity , the others the semantical thing, the mapping. 

NOTE : V7e assume that all sections on type specify the same mess, 
but do not list all of them^. 

- 6. 4; 3. 4 Set-types: In the last paragraph "S" seems to be 
the name of the semantical thing, but the wording "set of S" 
instead of set-of-S supports the syntactical viev;. In either 
case, it is used wrongly. 

- 6.5.1 Variable-declarations: In the second paragraph, "buffer- 
variable" is used for both, the syntactical structure and the 
semantical entity. 



- 6.6.3 Parameters: Formal parameters and actual-parameters are 
syntactical entities and do not possess a type! The type is 
possessed by the variable denoted by the parameters. 

Here we have a real clash in terminology, because we should 
better associate the type of a formal variable parameter 
with the parameter-identifier, not v/ith the denoted variable, 
since the denoted variable is the variable denoted by the 
corresponding actual-parameter. 

- 6.6.5.2 File handling procedures: On p. 38 the verbs "to 
denote" and "to .be" are used just the false way round. Some 
examples: "vl...vn denote variable-access" should read 
"vl...vn are variable-accesses", "Consequently it may be a 
component of a packed structure" should read "Consequently 
it may denote a component of a packed structure", since 
variable-accesses are pieces of text (like vl) denoting 
variables (like components of packed structures). 
Additionally, only the variable denoted by the file-variable 
f possesses a type, and read, readln, write, writeln are not 
procedures, but procedure-identifiers. 

- 6.6.5.3 Dynamic allocation procedures: P is a variable-access 
(a statement missing in the draft 1) and denotes a variable, 
which possesses a type and may be attributed a value. 

- 6.6.5.4 Transfer procedures; A can be a variable-access, not 
a variable, j and k don't possess types, and an expression 
does not have a value. 

NOTE: It is impossible to list all inconsistencies of 6.6.4, 
6.6.5 and 6.6.6. V7e assume that these section have not been 
untergone careful reading when introducing the distinction 
betv/een syntax and semantics. 

- 6.7.1 Expressions General: The first sentence states, hov; 
it should be: "An expression shall denote a value". The last 
paragraph on p. 43 and the NOTE, however, miss a number of 
"denote "s: "shall have the value denoted by x", "from the 
value denoted by x to the value denoted by y", "if the 
value denoted by x greater than the value denoted by y". 

- 6.7.2.5 Relational operators, 

- 6.7.3 Function designators, 

- 6.8.3.4 If-stateraents, and 

- 6.8.3.7 Repeat-statements: Here we find the v^ord "yields", 
which (possibly) reflects the fact, that the values denoted 
by the expressions are time-variant. We will comme to this 
point later. 

- 6.9 Input and Output: The points of 6.6.5.2 as to "to be", 
"to denote", "to possess a type" and to the distinction 
between procedures and procedure-identifiers apply here, too. 

As we have tried to show, the introduction of the syntax/ 
semantic-distinction, whi'ch made the draft much harder to 
read than its predecessors, resulted,. as undergone only 
half-hearted, in a draft being neither exact nor readable, 
while former ones were at least readable. 



We do not think that correction of all errors (or laxities) 
will do^ as the standard,* then, will be totally unreadable. 
Instead, we have two alternative proposals for further 
processing: 

1) Pull the approach to its end, but in a more suitable 
foriDr i.e. give a formal definition of P?^SCAL based 
on Oxford notation or the related and .more- convenient 
Vienna Development Method. This vzill establish an 
unambiguous reference for implementors and debuggers. 
Additionally, for the informal reader (he who would 
have been content v/ith one of the former drafts) 
annotate the formal definition with some text along 
the lines of one of the former drafts. 

2) Make the distinction between syntax and semantic totally 
clear by consequent wording, e.g. a syntactical non- 
terminal denoting some semantical entity x should be 
specified an "x-denoter". Pushing this approach through 
the draft will at least convert all inconsistencies 
and ambiguities into errors, which may be fixed by two 
ways, an exact one and a lax one: 

The exact one proceeds by inserting the V70rds 
"denoted by" at all places where. they are needed. As we 
mentioned earlier, the draft will probably become un- 
readable. The lax one includes' the sentence: "V7herever 
context makes clear whether an x or an x-denoter is 
addressed, the x-^enoter is used to name the x". Then v^e 
may throv; av;ay a lot of "denote "s and have to correct 
only some places (e.g. the first mentioned section on 
conf ormal-array parameters) . 

NOTE: V7e like proposal 1 better, since it is more clean 
and i:hus more suited for an international standard. 

At last, a fev7 v/ords on the defe)?red time-variance- problem: 
The relation betv/een a variable-access or a function-designator 
and its value is not as simple as the relation between a type- 
denoter and its type, but is t\7ofold: the variable-access 
denotes a variable, and that variable "denotes" the value 
actually attributed to it. The semantics of an assignment 
statement is a change only of the second relation, while a 
procedure call affects the first one. So we should not use the 
word denote to describe the relation between a variable- 
access and its value, and, as expressions incorporate variable- 
access, an expression and its value. 

In the denotational semantics the two-stageness is reflected by 
the use of tv/o different mappings, one relating the synctactical 
to the semantical entity, and one relating that to the value." 
By this, you can clearly describe hov/ different operations 
(assignment versus call) affect different changes in meaning. 
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Japanese Comments 

We S3W that'ihe sVcond draft proposal Tn"595) "had been extreoiela iap roved". ^ The 
elaboration done ba the editors shall be hiilhly appreciated. However, the 
proposal still contains several probleo.s to he considered carefully and, because 
some of theni are very essential, we are very sorry lo disapprove the draft this 
tine once adain. Our coBinents are as follows* 



!♦ Scope rules (6»2»2) 

1.1 According to 6.2.2,4, the rules 6.2,2.5 and 6.2.2.6 shall be exclusion 
principles. From this viewpoint, rule 6.2,2,5 seeas all ridht. However, 
_ _6,2,2.6 shall be amended as} 

~ -S.'2,2.6 The region ' CFist is tKi field-specifier "of a fiei'd-desidnator shall be 

excluded from the enclosing scopes. 

The original 6,2,2.6 expresses the same rule as one expressed in 6,5,5,3 and 
thus seems superfluous, 

_ 1,2 6,2.2.7 shall be attended as! 

0,2.2.7 There shall not be" two denHnd-polnt5"ofn,he' sa"iie identifier or label 

. for the same region. The original 6,2.2,7 'The scope of a defining point of an 
identifier shall include no other defining point of the same identifier* does 
not allow, say, the occurence of the value paraneter identifier because (see 
p,^3) the scope that is the foruial paraneter list of the defining point as a 

.....r^.r^"'?!'®'' identifier contains the defining point as the associated variable 
identifier fo f" the" reiion that is the BlocR, ' 



2. Conformant array parameters 

_.^V^ '^A-?'-^!^^'^ ^^^^ uiatter very_ iritensively and came to conclude that 

the comforniant-arfay-pafameters in the present"' form rs stiU too ad hoc and 
prei7.3iure. It makes it very hard to teach or explain the landua^e. It 
contradicts with the original aim of the lan^ua^e that is 'to make available a 
Jan^ua^e suitable for teaching programming as a systematic discipline based on 
certain fundamental concepts clearly and naturally reflected by the language' ♦ 

.^1^^^ parameters shall he introduced for 'writing of both 

system and application software' ," "the " inclusion of o'nly conformant array 
parameters seems not enough. We need more features. So, we strongly recommend 
to remove the conformant array parameters from the current draft. It shall be 
reconsidered together with other important extensions, after the current draft 
is standardized, • - ..... 

"~?',"2' *rsPB5i3iry-*we "don't ■lBre~"tTre~?iaTure "tb^ in3Icile~ v3TuV 3nH"virTa&Ii ■ 
parameters at the calling site. This is not the principle of Pascal but of 
Fortran, We can not accept the mixture of Pascal and Fortran. 

2.3 Descriptions for the conformant array parameters have not been brushed up, 
. JJl^.. li^^e 'The 3ctual_ parameter sjhall be either a variable access or an 

expression that is not s factof 'thaVii' is riot a vl'riSinccess'" is "b^S^idro'ur' 
understanding. Moreover, in the same clause, there are several Places where the 
expressions are meant in this sense without any comments. We think it would 
take long to improve the idea of the conformant array parameters. So, in order 
to approve the draft in one or two more editings, the discussion of the 
_*^£P.^o.':»'3nt array parameters shall be postponed to the later version. 



3, Syntax rules 



3»1 Groups of synlaK "rules in a clsuse are presented botloBi-up (ct» expression 
6f7.i) or top-down (cf. record types 6»4.3,3) or in ftixed order (cf» 
structured type 6i4.3«l)» They shall be presented in a systematic uay« 

3 .2 Throughout the whole syntax rules? there are nonterminal symbols which are 
defined but not referred to in other rules. They are only used in semantics • 
They afeT Pointer-type j pro^rani. fead-parameter-listi readln-paraneter-listi 
special-syjnboli siSned-nuniber; simple-typej structu red-tape » 

write-parsmeter-list and writeln-paraneter-listf They shall be indicated as 
such. (For instance with an asterisk, as in ALGOL 68.) There are nonterminal 
synbols that are referred to but not defined, They are! 
f ield-deji^nator-identifier* _ inte^er-tH pej _boole3n-typej_ _ char-tape and 
Teal-type. " field'-desi^natbr-identifief' "shall be definedi ""OthefsT shall "be 
indicated. 



A* B character rule for identifiers and A di^it rule for labels 

If the ei^ht character rule is not ad opted then the four didit rule shall be 

removed* - — - - — 

6.1.6 'that shall be in the closed internal 0 to 9999* -> empta. 

5. SsQuence type rules 6»4f3.5 

In rule (c)i coBiPonent c is also concatenated from the risht to define .last 
like x'^SCcJf ' SoV " the' rule" (h) shall he awendedf " 'and S(c)''x and x'^S(c) shall 
also be a seouencej' As a whole? the preciseness of description of the draft 
varies excessively from place to place. Accordingly the draft makes readers 
find the composition very unbalanced ♦ Ue believe English SPeakinS people will 
naturjilly feel the points by far wore sensibly than we did. 



6. Kew-type 

Types are denoted either by tape-identifier or new-tape. See p. 12. 

type-denoter = type-identifier 1 new-type . 
ordinal-tape = new-ordinal-type I . . . I 

ordinsi-type-identif ier . 
'Sol'similarry aTriy' type" shall" be 

ofre-.-t-Te = new-array-type I array-type-identifier . 

The lype-iientif ier vector shall be the arraa-tape-identif ier* not the 
structured-type-identifier. And so on» 



7. Editorial comments 

'•■',7 unsigned-real = unsigned-integer ('. ' »«« I'e' ... ) . 
p. 9 i*-lA Add 6.10 (defining point for input and output) 

^♦22 1.17 (a) Ti and T2 are the same tape which is permissible as a component 
tape of 3 file tape. (This is not the onla place where rules are to be 
interpreted recursivela. Remark for recursiveness shall be treated evenla.) 

■pT25 1.53 -the W^-fRe" - 

P.28 1.26 'forward* -> forward (In 6.1.4 forward is used without Quotes.) 

P.29 Insert This example is not for level 0.*)' to procedure declaration 

AddVectors. 

p. 31 1.4 the the -> the 

P.31 1.8 'forward' -> forward 

P.31 l.is Example of a procedure-and-function-declaration-part -> Example of a 

procedure-and-f unction-declaration-part { 
p-,16 1.7i8 (packed-conformant-arraa-schema 1 unpacked-conf ormant-arraa-schema) 



-> packed-conformant-arraa-schema 1 unpacked-conformant-arraa-schema 
p. 36 1,23 contains" -> closest-c'ontains" 

p. 36 1.25,26 -of 'array' 'C -> 1 of array C (Word sambols are not Quoted 

outside the santax rules,) 
p. 38 1,13j14 is is -> is 

p. 40 1,11 Insert 'write' and adjust indentation, 
_'*d9_P.?'flf ^ ' ^{l^i'^^te that p is the variable parameter, 
p.4i P3ck(5»i,2)!' indicate that z'is the variable" parameter , And so on. 
r',48 1,1 Add 'and J > 0' after 'i >= 0', 

P.51 1,-20 or to the function-identifier -> or to the function denoted ba the 
function-identifier (see 1,-9 when the variable or function does not have 
attributed ...) 

-•'^^.jil'r^^r^ '(*This example is not for level 0,*) ' to Procedure statement 
Addvectors, " " 

p. 53 1.2 6.8.3.3 conditional-statements. -> 6.8.3.3 conditional-statements 

(remove period, see 6.8,3.4 if-statements) 
p. 53 1.-6 Delete 'one of the case-constants ... to the case-statements . ' 

because the same meaning is containded in the next sentence 'it shall be an 

error if . , , upon entra to the case- state ment.' 
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CoBunept on Section 6.6.3.3 ^^T^ I 

Stat\ifi; Error 



PROBLEM: 

The^ current draft (TI85/2) says it is an error to provide Dispose with 
fewer tag arguments than were given New to crmate the object. The 
requirement that ■ not "be less than n is to avoid disposing more space 
than was originally allocated. However if m is greater than n, then 
it is approved to dispose less than was originally allocated and leave 
a dangling piece of storage space that cannot be reclaimed. It should 
be an error if the tag field list in dispose is not identical to its 
corresponding new. The argument that this may be too hard to detect 
is vacuous because, in the form "it shall be an error.,.", its 
detection is optional, 

RECOMMENDATION: 



Clio-ige "m is less than n" to "m is not equal to n" 



Comment regarding fUDctio.na 



STATUS : Error . 
PROBLEM: 

DPTl85/aecond edition does not currently «p«cify function results. 
InjparticulaLr , assignment to a function-identifier has the effect of 
attributing a value to the function instead of to an activation of 
the function. This ignores the problem of functions for which there 
exist Bore than one activation. 

Thus , for example , the f olloving program vill vrite the sequence of 
integers (2,1,0) according to the commonly held interpretation, but 
vill write the sequence (2,2,2) according to the specifications in 
DPTl85/second edition. 

program p(o); ^a "counter" examplej 
type natiii;_^l » 0..maxint; 
var o: file of natural; 

coTint: natural; 
fvinction f : natural; 
begin 

f : » count; 

if count <2 then 

begin count : « count + 1; write (o,f) end 

end ; 

begin rewrite(o); coxint : = 0; write(o,f) end. 

The solution to this problem requires the introduction of a new part 
of an activation of a f\inction which has many of the characteristics of 
a variable. This is a nontrivial change and requires alterations to 
6.2.1, 6.2.3.2, 6.2.3.3, 6.6.2, 6,7.3, and 6.8.2.2. 

PROPOSED CHANGES: 

In 6.2.1, last sentence, insert after the second conana: 
and any result of an activation. 

In 6.2.3.2, replace (e) with: 

(e) for each function-identifier local to the block, a 
function with the formal parameters associated with, the 
function-block corresponding to, and the result type 
associated with the function-identif ierj and 

(f) if the block b« a fxinct ion-block, a result possessing 
the associated result type. 

In 6.2.3.3, paragraph 2, append the clause: 

; except that the function-identifier of an assignment -state- 
ment shall, within an activation of the fxinction denoted by 
that function-identifier, denote the result of that 
activation. 

In 6.6.2, paragraph 3, change "possessing the type denoted" to: 
associated with the result type denoted 

In 6.6.2, paragraph 2, replace sentence 2 with: 

A f\inct ion -block shall contain at least one assignment- 
_ statement such that the function-identifier of the assign- 
■ent-statement is associated with the fxinction-block. 



In 6.6.2, paragraph 2, delete the last 2 sentences (revised 

restrictions are incorporated into 6.7.3, which is where 
they always should have been.) 

In 6.6,2, append the following the paragraph 5: 

; the block of the function -block shall be associated with the 
result type that is associated with the identifier or 
function-identifier, respectively. 

In 6.7,3, paragraph 1, replace sentences 1 and 2 with: 

A function-designator shall specify the activation of the 
function denoted by the function-identif ier of the function- 
designator, and shall yield the value of the result of the 
activation upon completion of the algorithm of the activation; 
it shall be an error if the result is undefined upon 
completion of the algorithm. 

In 6.8.2.2, paragraph 1, replace sentence 1 with: 

An assignment-statement shall attribute the value of the 
expression of the assignment-statement either to the variable 
denoted by the variable-access of the assignment-statement, or 
to the activation result that is denoted by the fxinction- 
identifier of the assignment-statement; the value shall be 
assignment-compatible wi+h the type possessed, respectively, 
by the variable or by the activation result. 

In 6.8-2.2, paragraph 3, sentence 1, change "variable or function" to 
"variable or activation result" (twice), and in sentence 2 and 
3 change "variable" to variable or activation result" (1* tines). 

JUSTIFICATION: 
Corrects an error. 



Comment on docxiaent X3J9/81-OO7 

(Dr. Arthur Sale's letter to Dr. Addyman of January 12, I98I. 
Status : Change 



Observation: 

We "have reviewed the document cited above. Ve took 
particular- note of items AHJS-8I/5 "definition of error" 
and AHJS-81/6 "definition of processor". 

We concur with Dr. Sale's evaluation and recommendations regarding 
these items . . 

no 
> 
CD 

m 



Coimnent on 6.9.1 I/O (P&g« 39) 

Status : Editorial 

Problem: 

The tern "legible" is not well defined and the ^rtiole paragraph is 
unnecessary. 

Proposed, change: Delete clause 6.9,1. 



Conunent on 5.1 Processor Compliance 
Status": Change 

Problem: Clause (e) doesn't really require anytliing. 

Proposed Change: In clause (e), replace "detect" with*detect and 
report"-. 

Justification: 

The change to clause (e) requires the processor to diagnose violations 
of the standard, at least at user option. 



Comment on 6.2.1 Blocks 
Status: Editorial 

Problem: The first and last paragraphs of this section are not about 
blocks and should be elsewhere in the text. 

Proposed Change: 

A new sub ^i ("K^-hxr^ ^ ,g m»h ^ lahoiiid be created^and titled 
"Labels". The first paragraph of 6.2.1 should become the text of this 
sub clause. 

The last paragraph of 6.2.1 should become the first paragraph of 
6.2.3.5. 

Justification: 

Each of the other declaration parts of the block has a section to 
ixself, viz.: 6.3 constants, 6.I4 types, 6.5 variables, 6.6 procedures. 
For parallelism, and so that the user may be able to find it, labels 
should have a parallel section, however small. 

The last paragraph of 6.2.1 is one of the activation rules and belongs 
next to the rule on the life of variables in 6.2.3.5- . This change also 
serves to organise the standard so that things may be found. 



Comment on 6.U.3.5 Textfiles 



Status : Error 
Problem : 

On page 21, the disclaimer on textfile structure does not 
go far enough. There is a real danger that some officially sanctioned 
validation suite may contain tests such as the attached program 
(reprinted from JPC/8O-061) . 

Proposed Change: 

On page 21, first paragraph, replace the last sentence "This 
definition... processor" with: 

"These provisions describe the functionality only, and shall not be 
constz-ued to determine in any way the underlaying representation of 
textfiles; in particular, the relationship, if any, between end-of-line 
and values of the char-tyx>e shall be implementation-dependent." 

Justification: 

There is too much myth about textfiles to permit the standard to gloss 
over many machine dependencies with a disclaimer on end-of-line. It 
suggests that one doesn't expect the end-of-line to be a space and 
that an implementor is not requireato have a chaxacter (byte) which is 
the end-of-line. But it does not make clear that the attached program 
is _implementat ion-dependent . 

Moreover, the original description in the UMfcR: "teXt * file of char" 
has led to more than one implementation-dependent program which the 
author believed to conform to all reasonable portability considerations 
in the UMWR. It is therefore necessary to dispel that notion in the 
standard by expressly stating the implementation-dependency of textfile 
I/O. 



program tested (output, textf ) ; 

{ 

This program tests whether textfiles handle the character set 
and end-of-line interrelations properly 

) 

const 

maxchr * 127 (the maximum ordinal value of type char 
in this case the value is 127 for ASCII); 

var 

textf : text ; 
fvalue : char ; 
c: integer; 
allok: boolean; 

begin 

( this section writes all of the char values to a textfile ) 

rewrite (textf) ; 
for c:«0 to maxchr do 

write (textf, chr(c)); . 
wr iteln ( text f ) ; 



This section reads all of the char values back 
and checks that they match what vas written 

> 

reset (textf) ; 
allok I =trae ; 

for c:=0 to maxchr do begin 

if eoln (textf) then begin 
writ e In ( output , 

'eoln unexpectedly returned true for c*', c:k); 
allok :«false 
end {if}; 

read (textf, fvalue); 
if fvalue <> chr(c) then begin 
vriteln (output , 
'file value was different for chr of', c:U, 

' value returned was*, ord (fvalue ) :U) ; 
allok :>false 

end (if) 
end (for c); 

( this section tests for end-of-line and end-of- fUe. ) 

if not eoln (textf) then begin 
write In ( output , 

' eoln did not return true after the last value ' ) ; 
alloJt:«fal8e 
end (if); 

re ad ( t ex t f , fvalue ) ; 
if fvalue <> ' ' til erv begin 
writeln ( output , 

' end of line value was not space ♦ It was chr of ' , 
ord (fvalue ) :U); 
allok: *fal8e 
end (if); 

if not ebf (textf ) then begin 

writeln (output , 'eof did not return true at end of file'); 

allok i=false 
end (if); 

if allok then writeln. (output, ' textf ile behaved as expectd'); 
write (output, '*♦* end of test •*•'); 

end* 



Comnent on various sections of the Second Draft Proposal for Pascal 
Status : Editorial 
Problem Statement: 

There are several places \rtiere the draft proposal would be improved or 
corrected by minor changes in spelling, wording and punctuation. 

Prxjposed Changes to the Draft Proposal: 



p. 3: In the first paragraph of section k change "the identifier of a 
predeclared or predefined entity '^ to "the identifier of a required entity" 



p. 11: In the last paragraph of section 6.3 change "The constant shall not 
contain" to "The constant in a constant-definition shall not contain". 

p. 15: In section 6,k,3'2, in the paragraph that follows Example 2, change 
"by the index type. Then the values" to "by the index type; then the 
values". 

p. l6: In the last NOTE of section 6.U.3.2 change "which, allow" to "u)Kic^ a(.(.oui . 

p. 19: In the paragraph following the second note of section 6.14.3.14 change 
"unpacked set designated the" to "unpacked set type designated the". 

p. 57: In section 6.8.3.10 add the syntax definition: 
field-designator-identifier « identifier. iL«n^o-f 

p. 35: In section 6.6.3.6 subparagraph (e) "index -type -specifica- 

tion". 

p. 37: In the third note of section 6.6.3.7 (first note at top of page) 
change "can not" to cannot". 

p. 36: 2nd paagraph from the bottom, replace \he -TK"^^ boo^Jo- ^-^^'-^'^^ ' 

*QfpUe^ occurrences ^i'rs-<^ idet^V-f^f^ " (xr^^ replace "^e s>ectf»a fcu»'t-io€^/n ne^" 

In 6.U.1, paragraph 2, the phrase "its type-denoter" is poor; change to 
"the type-denoter of the type -definition' . 

In 6.6.1, delete the first paragraph; the first sentence is meaningless, 
the second is redundant (see 6.2.3'3)' 

In 6.6.1, paragraph 3, change "the the" to "the". 

In 6.6.1, clarify the meaning of paragraph U by changing "in the same 
procedur;-and-function-delaration-part" to "closest-contained 
procedure-and-function-dedaration-part closest -containing the procedure- 

heading" . 

In 6.6.1, paragraph 5, change "associates" to "shall associate". 

In 6.6.2, delete paragraph 1; the first sentence is meaningless, the second 
is red\mdant (see 6.2.3*3) « 

In 6.6.2, paragraph 3, change "the the" to "the". 

In 6.6.2, clarify the meaning of paragraph k by changing "in the same 
pr(5?iedure-and function-declaration-part" to "closest-contained by the 
procedure -and-funct ion -part close^-contaiang the function-heading". 

In 6.6.2, paragraph 5, change "associates" to "shall associate". 



Conwnt on U. DEFINITIONAL COHVEKTIOKS 



Statut : Error 

Problwn: Definition of "a y containing an x" d«fina« a y to ba an x. 
Proposad Change: 

Reword definition to raad "a y containing an x: rafari to any y from nhich 
an X if directly or indirectly derived." 

Justification: 

The proposed wording defines a y to be a y. 



Comnent on ISO 2nd DP 



Status : Editorial 



Problem ; 

In previous drafts, appearances of a wprd-sypibol or required identifier 

in the text were underlined when necessary to distinguish them from English 

words. This underlines have all disappeared in the second DP. 



Proposed Change; 

Restore the underlines as in previous drafts or use a different typeface . 

The locations affected include: 

6.1. U forward, external 

6.k.2.2 integer, real, Boolean, false, true, char 

$.U.3.1 packed 

6.k.3,5 text 

6.U,l4 nil 

6.6,5.2 read, write 

6.7,1 not 

6.7.2.2 maxint 

6,7.2.5 in 

6,8.3.n then, alse 



Justification: 

Readability is enhanced by distinguishing language 
elements from English words. In many of these ca?e?, t^e 
sentence is gramatically incorrect unless this distinction 
is Bade. 

Comment pa Note in 6,1.U 
Prpblep ; ' 

In 6.1,U^ %he no-^e cannot be dedHcedl from the text of the 
8tand?ird and ip irrelevant . 

Status ; Editorial 

Recommendation: Delete the note in 6.1. U. 



Comment on 6.6.5.3 (Dynamic allocation procedures) 



Statxis : Error 
Problem Statement: 

The description of the second form of dispose uses the 

construct "q'*'* where q represents a pointer expression. This use of "q"" 
is not defined by the draft proposed Pascal standard because an 
identif iedrvariable can only be constructed from a pointer-variable and q' 
is a pointer expression . 

Proposed Change to the Draft Proposal: Change "q''" in the description 
of the second form of dispose to "the pointer value of q" . 



Comment on 6.10 (Programs) 
Status ; Error 
Problem Statement; 

Kie draft proposal requires that if the required variables input or output 
are specified as program -parameters then these identifiers must be 
declared in the variable-declaratipn-pai-t of the program block. This is a 
change from the Pascal User Manual and Report which states that the program 
parameters input and output must not be declared as variables in the 
program block. 

Proposed Chzmge to the Draft Proposal; 

In the first paragraph of section 6,10 change "each program parameter 
shall be declared" to "each program parameter shall have a defining -point 
as a variable-identifier for the region that is the pro gram -bio ck" , 



Comment on 6. 8.3 ♦3 Case -Statements 



Status : Error 
Problem: 

The_ last sentence of the first paragraph is contradicted by 
the" second paragraph. The former states the requirement tha't'one of the 
case -constants shall be equal to the value of the case-index, making 
detection of violation mandatory (by 5-1) > while the latter states the 
violation shall be an error, making the detection optional (by 3.1). 

Proposed Change; Delate the second paragraph. 

Justification; 

As they stand, the two statements are obviously 

contradictory, The. selection of mandatory detection is dictated by 
consistency with the majority of current Pascal implementations, rigor, 
robustness, and the desire to be able to prove programs correct. 



Conunent on Scop€ of procedure and function header (s) 



Status : Change 

Prohlem Statement: 

-Scope of identifiers appearing in procedure and function headers 
is unnecessarily complicated 'by the sepairation into tvo regions 
(and two scopes). This allows programs which appear contradictory, 
and complicates an accurate description in reference manuals. Xt appears 
to have no compensating advantages. 

Example: 

fvmction Func(Parajn : integer) : integer; 
type 

Integer « char; 

begin 

/body of func/ 
end; 

In the example, the appearances of 'integer' in the function header 
do not correspond to the type 'Integer' declared within the function. 
Specifically, type identifiers (and the procedure /function identifier) 
may be redefined within the procedure/function; parameter identifiers 
say not be redefined. 

Re commendation : 

Modify the scope rules so that any identifier that appears in a 
pro cflfdure /function (including the header) may have only one meaning 
throughout that procedure /function. 

A possible (and desirable) effect of this change would be "6& prohibit 
redeclaration of a procedure identifier immediately within the 
original procedure. (Note that this redeclaration is already 
prohibited -for fun^ion identifiers, as no assignment to the function 
value could be made . ) Note also that this would restore the 
correctness of statements in sections 10 and 11 of the Revised Report: 
"The use of the [procedure /function] identifier ... within its 
declaration implies recursive execution." 



Comment on 6. 6.3 » 7 Conformant Array Parameters 
Status : Change 
Problem : 

The technique newly introduced in dp7l85 of requiring the calling 
procedure to determine -^Aether a given actual parameter is to be ]>ass«d 
by "reference" or "value" has several problems: 

(1) It assigns a new semantic meaning to a syntax ^ich formerly had a 
different semantic meaning - it makes the parens significant in (X) • 

(2) It is unlike any similar construct in the Pascal language defined by 
the standaxd 

(3) This very departure from the rest of the language creates confusion 
for the user and leads easily _ to invalid programs. 

{k) It creates an xinnecessary limitation on implementations. 



Moreover, this problem is merely the latest in a long string of 
dif f iculties . in getting a technically robust conformant -array- 
proposal. It is not clear that it is the last such problem, since 
several difficulties with the previous proposals remain xmsolved in 
the current proposal. 

These problems arise out of the attempt to put the conformant-array- 
extension into the standaord and, in particular, to do so in a strange 
fashion so that minimal impact on existing implementations may be 
felt. This approach has real penalties. We suggest four alternatives 
below, the first one being oxir preference: 

(1) Remove the conformant axray featxirc entirely and leave only the level 
0 language. 

(2) Allow both "value" and "var" conf ormanf^aSameters , without unusual 
restrictions, in exactly the same ivay that "value" and "var" 
parameters of any other type may be specified, admitting that this ^^Q-^ 
require runtime specification of the size of the activation record in 
some instances ; or 

(3) Delete the "value" conformant -array-parameter construct entirely, 

and therewith the attempt to permit string manipulation via conformant 
array parameters. 

{k) Consider as an alternative for further study document J'PC/80-2U£ 
(attached) . 

Proposed Change: 

The above options are in order of preference. If the feature is deemed 
■o desirable that it cazmot be removed, it must be made adequately robust. 

Justification: 

(1) Some compilers may have a serious problem distinguishing A from (A) 
in an actual parameter sp€y=if ication, nominally because of the use of 
bottom-up paxsing mechanisms in the expression parser. While one may 
argue that marginal coirpiling techniques should not be encouraged, 
others may argue with as much right that runtime storage management 
mechanisms should be sufficiently robust to tolerate nmtime 
specification of the activation record sizes. 

(2) Consider the procedure WORKON defined to produce an array T by some 
activity on the elements of array X, for example, transpos^ion. With 

_ fixed array types, the procedxire would look like: 
type vector ■ array [1. .50] of reed) 

procedure WORKON ( X: vector; var T:vector) ; 

var i: I..50; 
begin 

for i :« 1 to 50 do 
T[i] :« X[51 - i]; 

end; 

and if A is a vector, then WORKON (A, A); can be expected to transpose 
A over its€l>P correctly. But if a conformant array schema is used: 

procedure WORKON f|far X, T : array [lo..hi: integer] of real); 
then WOPJaXA, A) will fail strangely, and WORKON ((A), A) is required. 

The annoying thing about this failure is that the latter procedure is 
the one which is expected to be put in a source library to be copied 
into the user program and used without other than black-box 



documentation. The problem vith the proposed syntax is that the 
proced\ire cannot protect itself from misuse - it must depend on the 
caller to use it correctly. And yet the avowed intention of the 
construct in the first place vb.s to permit the construction of 
proced\ire lilAries which were essentially independent of the types in 
the calling program. 

The proposal eliminates a desirable implementation method. The 
proposal requires the calling program to allocate the copy of the 
variable, where for code economy the implementor may prefer the called 
program do so. 

A number of objections to conforn&nt array parameters as previotialy 
specified still stand as objections to the current proposal: 

(a) They emphasize structural compatibility of types, a phenomenon 
which is avoided in the theoretical studies of Pascal and in the draft 
proposed standard, in each case with great deliberation. Several 
other proposed modifications to permit structural compatibility of 
anonymous types have been firmly rejected on the basis of the 
importance of type identification and name -compatibility of types. 
This feature is deemed to be of such value that its consistency with 
such cherished characteristics of the language is of no consequence. 

(b) Conformant array schemas provide no method of construction of a 
type-denoter for the types they represent. As a consequence, no 
related compatibilities can be specified, as between arruys and 
vectors, for example, and such compatibilities as may be required in a 
given procedure aust be checked by user code at nintime. 

(c) The expectation that many procedures using conformant array 
parameters will be included from source libraries creates a real 
problem in the intelligent use of the "ordinal-type-identif ier" in the 
index-type-specification. Since such type-identif ierx would in 

most cases be limits on the capabilities of the procedure, and would 
have to be source -included in a program which has no other use for 
^hem, it is likely that in the average installation the ordinal-type- 
identifier would usually degenerate to integer. Thus in most cases, 
any limitations the procedure really has must be protected by user 
code runtime checks. 

(d) Because of the conformability. rules , the use of "ordinal-type - 
identifier" doesn't prevent the system from having to perform 
runtime checks for the compatibility of index-type-specifications. 
Consider: 

type rglO «-1..10; rg20 » 1..20; 
var A: array [rglO] of real; 

B: array[rg20] of real; 
procedure array [lc». .hi:rg20] of real); 

procetJure, QCVA^ Y-'arroj 
If procedure P contains the statement Q(X) ; 

then P(A); is valid, but P(B) is invalid. And if the call on Q is 
conditional, e.g. if hi^lO then Q(X) ; 

then even P(B) is valid, but the proof is in the ta^ - you find out 
at rxinjtime. So the system has to perform the runtime check, or say 
that it doesn't, of course. 



Comment on 6.6.3.7 Conformant -array -parameters (p, 37) 



Status : Error 
Problem: 

The beginning of the paragraph following the first note on page 37 
_ contains an elaborate specification ^ich reduces to nothing of value. 
' It contains at least one incorrect occurrence of "not" in "not a 

factor- that is not a variable-access." It clearly does not represent 

the author's intent. 

Proposed Change: 

In the paragraph following the first note on page 37, delete the first 
sentence and the beginning of the second sentence lip to "expression", 
and replace thera with: 

"rne actual -parameter shall be an expression. If the actual-parameter 
is not a variable-access,"... 

Justification: 

The only English -language parse of the first sentence yields: 
"The actual-parameter shall be either (a) a variable-access, or 
(b) an expression which is not denoted by a factor." (The clause 
"not a factor that is not a vaxiable -access" translates to: "if 
it is a factor then it must be a variable-access", which is allowed 
by the first 8i>ec.) 

Uhfoz-tunately, the only expressions allowed under (b) are those which 
contain relational-operators , adding -operators , or 

^"■'tiplying-operators, none of which can yield a value of array-type 
except by extension to the proposed standaird. Moreover, the 
recommendation in the following note, that a "value" parameter can be 
constructed by the form "(A)" conflicts with the stated requirement, 
because the form "(A)" is a factor which is not a variable -acces s . 
So it is very unlikely that this restriction was intended as written. 

It is not difficult to allow the generalization to "expression", since 
the conformability requirement will eliminate most possible productions 
and leave exactly three possibilities within the proposed standard: 
variable-access, character-string, and "(variable-access)". (It also 
allows any number of redxmdant parentheses aroxind any of the three 
possibilities.) It is not clear whether the author intended to 
prevent character- string as a possibility, but it seems unnecessary to 
do so. Character- string parameters present no difficulty to the 
compiler-writer and considerable advantage to the user, whereas the 
form (A), which was clearly intended, causes additional headaches for 
the compiler-writer and the author of this standard. 

It should also be noted that the generalization to "expression" allows 
implementations which support array arithmetic or array-valued 
functions to be included automatically without further local 
■edifications to the conformant -array-parameter rules 



Comroent on 6,6.3 > 7 Confonnant-array-paraaeterg (p« 37) 



Status : Error 

Problem: On page 37 in the second paragraph after the second note, 
hegiiining "If the actual-peo-aaeter is an expression vhose value is denoted 
"by a variable -access," the condition given is incorrect in tvo vays; 

(1) The expression which is a variable-access is alj^o^^g^tV^^ 
expression vhose value is denoted by a variable-access imitations 
should not be applied, since the j-ule above specifies that the 
parameter shall be pa ""by reference" in this case, 

(2) When the actual-parameter is an indexed-variable , the variable -access 
that is the actual-parameter is never the variable -access that 
closest-contains the conformant -array -parameter identifier — the 
array-variable is. 



Proposed Change: 

At the end of the first paragraph of 6.6.3-7 (p.35) , a-dd: 
"A parameter-identifier so defined shall be designated a conformant- 
array-parameter." 

At the end of the paragraph at the top of page 37, just before the note, 
insert: 

"The type denoted by the type -identifier contained by the conformant -array- 
schema in a conformant-array-parameter-specification shall be designated 
the fixed- component -type of the conformant-array-parameters defined by that 
conformant -array-parameter- specification. " 

Replace the second paragraph after the second note on page 37 with: "If the 
actual-parameter is not denoted by a variable-access and the 
actual-parameter contains an occurrence of a conf ormant-arrayparameter, 
then for each occurrence of the conformant-array-parameter contained by the 
actual -parameter expression, either 

(a) -fhe occxirrence of the conformant -array -parameter shall be contained by 
a function-designator contained by the actual-parameter expression, or 

(b) the occu2*nce of the conformant -array-parameter shall be contained by 
an indexed-variable contained by the actual-parameter expression, such 
that the type of that indexedvariable is the fixed- component -type of 
the conformant-arra55>arameter. 



Justification: 



(1) If the actual-parameter is an expression "«^ose value is denoted by a 
variable -access, itmoakx^he form V, i^ereas the expression the author 
wants to limit has the form (V) , because the former is passed by 
reference (and therefore is no problem) , but the latter is passed by 
value, and its size must be known at compile — time. 



(2) The idea is that if the actual -pai-ameter contains a formal pai-ameter 
from a higher-level activation and that formal parameter is itself a 
conforroant-array-parameter, we want to be sure that we are not 
required to pass on something of unknown length, unless we can pass it 
by reference. Ifefortxinately , the variable -access irtxich 
closest-contains the confoiTnant-Arrav.-parameter is the .vaariable-access 
Of the vacriable -access which is the actual-^parameter. 



(3) Regr^ably, there is no good way to specify the particulsir syntactic 
entity which may not contain a conformaint-array-pararaeter unless it is 
adequately subscripted. Consider the descent for (A[I]): expression, 
simple -express ion, term, factor, (parens) expression, 
simple -express ion, term, factor, variable -acces s , component -variable , 
indexed-V'iriable , (a) array-variable, variable -acces s , 
entire -variable, variable-identifier, identifier; (b) (brackets) 
index -express ion, expression,... It is easy to leap to the 
conclusion that indexed-variable is the target entity, but note the 
ancestral tree you have to give to distinguish the one you mean from 
the possible occurrence of another one in the index -express ion. 

The proposed change discards this approach in favor of a such more 
global, but apparently adequate, limitation. The weakness is that the 
proposed change assumes that there can be no legal operators on 
conformant-array-parameters per se, only on the fixed- component -type . 
Of course, it is always possible for the conforroant-array-parameter 
to be passed to a function used in the computation of some value in 
the actual -parameter expression. So option (a) allows this, noting 
that the conformant-array-parameter will have to satisfy the usage 
coxltraints as an actual-parameter to that function. 

(U) Note that the changes contain two insertions to define terms so 
that the restriction on actual parameters is comprehensible. They are 
not strictly necessary, but the existing wording for 
"conformant -array -parameter" requires an additional clause: 
"def ining-occvurrence for the block which contains the 
actual-parameter..,". The existing (a) and (b) could be combined 
into a replacement for the proposed (b) , and thus remove the need for 
defining "fixed-component-type", leaving as much of the existing texx, 
as little comprehensibility, as possible. 



Comment on FOR statements 
Status : Change . 

Problem: DP7l85/second edition changes the status from error to 
requirement in 6,8.3>9 ^or assigning-references within a for- statement. 
This nay cause difficulties for some implementations . Consider 
procedure p; 
~ var i: integer; j: integer; 

function f : integer; 
begin 
f :« 0; 
i :- 1 
end; 
begin 

for i :« 1 to 10 do j := f 
end 

Without flow analysis or other relatively expensive mechanisms it is 
very difficult to detect the modification of i within f . This problem 
is very difficult in general and the space -overhead in compilation can be 
a burden. 

Proposed Change: In 6.8.3.9, paragraph 2, replace sentence 3 with: 
Neither the statement of a for- statement nor any procedure - 
and-function-declaration-part of the block that closest-contains 
a for-statement shall contain a statement threatening the 
variable denoted by the control- variable of the for-statement. 



Aad a new paragraph to 6.8.3'-9' 

A statement S shall be designated as threatening a variable 
V if one or more of the following is true, 

(a) S is an assignment -statement and V is denoted b7 the 
variable-access of S; 

(b) S contains an actual variable parameter which denotes V; 

(c) S is a procedure-statement that specifies the activation 
of the required procedure read or the required procedure 
readln, and V is denoted by an actual parameter contained by 
S; 

(d) S is a for-statement and the control-variable of S denotes V. 

Justification: 

The present restrictions are unnecessarily complex and 
costly to enforce; as a consequence implementations are likely to not 
enforce them. It is preferable from the user's point of view that such 
parts of the language be enforced to promote the detection of programming 
errors and to avoid the creation of non- conforming programs. The proposed 
change is simpler to \inderstand, more likely to be enforced, and in 
addition to the above advantages for users, allows the removal of nm-tiaie 
checks from for-statement loops. 



Comment on section 6.1^.2.3 (Procedure -statements) and section 6.9 (Input 
and output) 

Status : Error 

Problem Statement: The non-terminal symbols read-parameter-list, 
readln-parameter-list, write -parameter -list and writeln-parameter-lift 
are never used in other syntax productions. 

I^oposed Change to the Draft Proposal: 

In section 6.8.2.3 add the following to the end of the first paragraph: 

The procedure -identifier in a procedvire-statement containing a read- 
parameter-list shall denote the required procedure read; the 
procedure-identifier in a procedure- statement containing a 
readln-parameter-list shall denote the required procedure readln; 
the procedure -identifier in a pro cedvire- statement containing a 
write-parameter-list shall denote the required procedure write; the 
procedure-identifier in a procedure -statement containing a writeln- 
parameter-list shall denote the required procedure writeln. 

In the same section modify the definition of procedure-statement to read: 

procedure -statement = 

procedxxre- identifier 

( ,[ actual -parameter-list] I 
read-parameter-list | 
readln-parameter-list I 
write-parameter-list | 
write In -parameter- list ) . 



Comment on non-existence of applied occurrences 



Status : Error 

Problem: In subclause 6.2.2, the word identifier is used with (at least) 
four different meanings. In 6.2.2.1, it conforms to the (syntad:ic) 
definition given in 6.1.3. In 6.2.2.5) it refers to homonyms: two 
di^erent syntactic identifiers having identical orthography but di^Terent 
derivations and meanings. In 6.2.2.7, there is the syntactic meaning as 
well as the meaning of homograph: having identical orthography. Then in 
6^2 ^ . 9 it> untenable . To correct it, remove all usages of identifier (and 

I a.bel) that conflict with the definition given in 6.1.3. 

Ch o^to do uirt\^-tiie s<zt o^. ;^p^^'^rs . ^OcU CoviAAjStgvi iLS 
Proposed change: ' ■ — 

Replace 6.2.2.5 by 

When an identifier or label has a defining -point for region A and another 
identifier or label having the same spelling has a defining -point for some 
region B enclosed by A, then region B and all regions enclosed by B shall 
be excluded from the scope of the def ining-point for region A. 

Replace 6.2.2.7 by 

The scope of a def ining-point of an identifier or label shall include no 
def ining-point of another identifier or label having the same spelling. 

In 6.2.2.8, cheinge "all occuilinces of that identifier or label shall be 
designated applied occurrences" to "each occurrence of an identifier or 
label having the same spelling shall be designated an applied occurrence 
of the identifier or label of the def ining-point" , 

In 6.2.2.9, change "a type- identifier may have an applied occurrence in 
the domain-type" to "an identifier may have an applied occxirrence in the 
type-identifier of the domain-type". 

Justification: Without this change there aire no applied occurrences. 



Comment on File Handling Procedures (6.6.5.2, 6.9.2, 6.9.3, 6.9.^, 6.9.5) 
Status : Error 
Problem Statement: 

Section 6.6.5.2 defines read(f,v) to be equivalent to: 

_ begin v :« f^; get(f) end 
and" write (f,e) to be equivalent to: 
begin ^'V/jT •» 

The jy^'oftaoi (If'^fi ^f^^^^n contains a note making it clear that read is 
equivaJLent to the specified compovmd statement and not to a procediire 
whose body is the compound statement. 

Consider the following variable declarations: 
var 

fa : array [1 . . 10] of file of integer; 
ftext : array [0 .. 256] of text; 
a : array [l . . 10] of real* 
i : integer; 
c : char; 



The proposed Pascal standard leads one to believe that read(fa[i] ,i) is 
equivalent to: 

begin i :» fati]-^; get(fa[i]) end 
and that writeCfaLfata]"] >i) is equivalent to: 

begin fn.[tix[2]''r i; put (f a [fa[2] ) end 
By choosing the proper values for the variables its possible that the above 
read statement vill read an integer value from the file buffer of one file 
but do the get operation on a different file. Likewise, the above write 
statement can do an assignment to the file buffer of one file but do the 
put operation on a different file. The above behavior is even aore 
spectacular Mhen textfiles are used. The propDsed Pascal standard does 
not seem to adequately define the effect of: 

readln(ftexti ord(ftext [i]")+ord(eoln(ftext[ord(c)] )) J, i, a[ij, c) 

The Pascal file handling procedures should not be defined so that the 
file variable being accessed can change during the procedure exevution. 



Proposed Change to the Draft Proposal: 

JPC believes that this is an iaportant correction to the Pascal standard. 
However, the complexity of the issue precludes a reliable solution in the 
time allotted. The exact wording of the correction should be considered by 
ISO/TC 97/SC 5/WG U. An example of an attempted correction follows: 

In section 6.6.5.2 change the definition of read to: 

Ut f be a file-variable and vl...vn be variable-accesse^then the 
procedure-statement read(f ,vl, . . . ,vn) shall access the file variable and 
establish a reference to that file variable for the remaining exeo^ion of 
the statement. The remaining execution of the statement shall be 
equivalent to 

begin read (ff,vl); ... ; read(ff,vn) end 

where ff denoteJ the referenced file, variable. 

Let f be a file-variable and v be a variable-access; then the procedure- 
statement read(f ,v) shall access the file variable and establish a 
reference to that file variable for the remaining execution of the 
statement.' The remaining execution of the statement shall be equivalent to 

begin V :« ff^; get(ff) end 

where ff denotes the referenced file vairiable. 

In section 6.6.5.2 change the definition of write to: 

Let f be a file-variable and el... en be expresp-ons; then the procedure- 
statement write (f ,el, ... ,en) shall access the file variable and establish a 
x«rx,:.'ence to that file variable for the remaining execution of the 
statement. The remaining execution of the statement shall be equivalent to 

begin write (ff, el) ; ... ; write(ff,en) end 

where ff denotes the referenced file variable. 

Let f be a file-variable and e be an expression; then the procedure - 
statement write (f,e) shall access the file variable and establish a 
reference to that file variable for the remaining execution of the 
statement. The remaining execution of the write statement shall ba 



equivalent to 



begin ff^ :« •; put(ff) end 
i^ere ff denotes the referenced file variable. 
In section 6.9*2 change subpaii^raph (a) to: 

(a) read(f ,vl, . . .vn) shall access the textfile variable and establish a 

reference to that textfile variable for the remaining execution of the ^ 
statement. The remaining execution of the statement shall be ^ 
equivalent to 3> 
begin read (ff,vl) ; ... ; read(ff,vn) end 

where ff denotes the referenced textfile variable. £ 

00 

In section 6.9.2 change subparagraph (b) to: 

=1*: 
ro 

(b) If V is a variable-access possessing the char-type (or subrange ^-* 
thereof)) read(f,v) shall access the textfile variable and establish a 

reference to that textfile variable for the remaining execution of the 
statement. Th^ remaining execution of the statement shall be equivalent 
to 

begin v :« ff*^; get(ff) end 
where ff denotes the referenced textfile variable. 
In section 6.9<2 change the first sentence of subparagraph (c) to: 

(c) If V is a variable -access possessing the integer-type (or subrange 3-, 
thereof), read(f,v) shall access the textfile variable and establish a ^ 
reference to that textfile variable for the remaining execution of the 

statement. The remaining execution of the statement shall cause the r" 
reading from the referenced textfile variable of a sequence of characters. ^ 

In the last sentence of subparagraph (c) of section 6.9.2 change ^ 
"the buffer-variable does not" to "tlxe buffer-variable of the referenced 
textfile does not" 

In section 6,9.2 change the first and last sentences of subparagraph (d) 
similiarly to the change of subparagraph (c) . 

In section 6,9.3 change the definition of readln to: 

Readln(f ,vl, . . . ,vn) shall access the textfile variable aind establish a 
reference to that textfile variable for the remaining execution of the 
statement. The remaining execution of the statement shall be equivalent to 

begin read(ff ,vl, . . . ,vn) ; readln (ff) end 

where ff denotes the referenced textfile variable. 

In section 6.9.U.I change the definition of write to: J 

CD 

Write (f ,pl, ... ,pn) shall access the textfile variable and establish a ^ 
reference to that textfile variable for the remaining execution of the ^ 
statement. The remaining execution of the statement shall be equivalent *~ 
to 



begin write(ff ,pl) ; ... ; write (ff,pn) end 



where ff denotes the referenced textfile variable. 



In section 6.9.5 change the definition of writeln to: 

Writeln(f ,pl, . . . ,pn) shall access the textfile variable and establish a 
reference to that textfile variable for the remaining execution of the 
statement. The remaining execution of the statement shall be equivalent* 
to 

begin vrite(ff, pi, ... ,pn) ; vriteln(ff) end 
where ff denotes the reference textfile variable. 



ATTACHMENT H 

Schema Array Proposal PART 2 

USA Contribution on Schema Arrays for Pascal 



Abstract 

This proposal introduces a new concept into Pascal - the schema. Once 
defined it solves the same problem that conformant arrays attempted to 
address. The principle advantage with this mechanism is that ir provides a 
broader base on which to build; it resolves many of the problems foxmd 
with conformant arrays and offers the opportunity to provide other fea- 
tures in the future should the need be determined. 

The problem addressed by conformant arrays is one of how to pass arrays 
into a procedure or function in such a way that the boimds of the array are 
provided by the actual parameter - rather than by the formal parameter. 
This fvmction is very desirable in the context of being able to write 
generic procedures and functions. 

This proposal will be based upon X3J9/80-192 with references to conformant 
arrays omitted. 



Overview 

A schema can be thought of as a collection of types; each member of the 
collection is related to the other members in that they each have the same 
overall structure. The structure of e*ach type is that of an array with the 
same component type. However, each array has a different index-type. 

Ve permit a parameter of a procedure or function to specify that it will 
accept any actual parameter whose type is a member of a specified schema. 
In this way we permit the procedure or function to operate on a number on 
values with different types, although only from the same schema. 



Proposal 

In section 6.2.1 modify the production for type-definition-part: 

type-definition-part = 

( "type" ( type-definition | schema -definition ) ";" 
{ ( type-definition I schema-definition )";")] . 



Effect 

This says that the type-definition-part of a block is composed of any num- 
ber of type and schema definitions. 



Modify the production in section 6.4.1 for a new-type: 



new-type = new-ordinal -type | new-structured-type | 
new-pointer-type | discriminated-schema . 



Effect 



This specifies that a new-type may be created by any of the existing means 
in Pascal or by selecting one of the members of a schema. 



Add a section between 6.4 and section 6.5: 

6.x Schema-definitions 

6.x. 1 General. A schema-definition shall introduce an identifier to 
denote a schema. A schema defines a collection of new-types whose type- 
denoter is a discriminated-schema. 



schema-definition = 

identifier formal -discriminant -part array-schema . 

formal -discriminant -part = 

discriminant -specification 
{ ";" discriminant -specification > . 

discriminant -specification = 

identifier-list ":" ordinal -type- identifier . 

array-schema - [ "packed" ] "array" "[" schema-index-type 
{ ; schema -index- type } "]" "of" component -type . 



schema- index -type = ( constant | discriminant -identifier ) 
( constant | discriminant-identifier ) . 

discriminant-identifier = identifier. 

schema-identifier = identifier. 



The occurrence of an identifier in a schema-definition of a type- 
definition-part shall constitute its defining-point for the region that 
is a block. Each applied occurrence of that identifier shall denote the 
same schema. Except for applied occurrences of the identifier in a 
discriminated-schema as the domain-type of a pointer-type, the schema 
shall not contain an applied occurrence of the schema -definition. 

Effect 

The above definitions add the mechanism by which to define a schema. The 
leading identifier on the schema-definition (schema-identifier) becomes 
known. A schema may not have any references to itself except when used as 
the domain of a pointer; and in that case, it must only be used with the 
actual -discriminants (discriminated-schema). Thus, a schema has the same 
scope as a type declared at the same place. 

i ^ 

Add a section after 6.X.1 

6.x. 2 Formal -discriminant -part. The forraal-discriminant-part in a 
schema-definition shall define the formal-discriminants. The occurrence 
of a identifier in a discriminant-specification shall constitute its 
defining point as a discriminant-identifier for that region of the program 
that is the following array-schema. 

For every discrimina at -identifier in formal-discriminant -part, there 
shall be at least one applied occurrence in the array-schema. The occur- 
rence of a discriminant-identifier in a schema-index of an array-schema 
shall specify that there is one type-denoter which is ' a member of the 
schema for each allowed value of the discriminant-identifier such that all 
other schema- index values in the schema are the same. 

Note: this implies that the number of type-denoters in the domain of the 
schema is the product of the number of values for each occurrence of each 
discriminant-identifier. 

Effect 

The formal -discriminant-part is used to associate identifiers with the 
schema so that the domain (members of the schema) can be determined. Every 
identifier used in the formal-dsicriminant must be used at least once in 
the following array-schema. In the following; example, SmallVect is a col- 
lection of ten type-denoters with index-types "O..I", "O. .2", ... , 

"0. .10". 

type 

Smallint =1 .. 10; 

SmallVect (HighBound : Smallint) = 

array [ 0 HighBound ] of Real; 



Add a section after 6.x. 2 



6.x. 3 Discriminated-schema. A discriminated-schema selects one of the 
members of a schema as a new- type. The discriminant -values are bound to 
their corresponding discriminant-specifications in the formal - 
discriminant -part for the schema. The number of discriminant values must 
be equal to the number of formal -discriminants and each value must be 
assignment compatible with the type of the corresponding formal- 
discriminant - 

discriminated-schema = schema-identifier actual-discriminant-part , 

actual-discriminant-part = "(" discriminant-value 
( discriminant -value ) ) . 

discriminant -value = constant . 

Any schema designated packed and denotes an array-schema having its 
schema- index- type specifying its smallest value a constant whose value is 
1, and having as its component -type a denotation of the char-type, shall 
be a string-schema. Any new type specifying a discriminated-schema which 
is a string-schema shall be designated a string-type. 

Effect 

A discriminated-schema is a type-denoter selected from the collection of 
type-denoters in the schema. The values given in the actual - 
discriminant -part are used (substituted) for the formal-discriminants in 
the array-schema. Thus the discriminated-schema: "SmallVect(7) " selects 
the member of the schema which is equivalent to (but not the same as) the 
array : 

array [ 0 . . 7 ] of Real 

An attempt to specify the schema as "SmallVect (11) " will result in an 
error because the value 11 is not assignment-compatible with the type of 
HighBound. 

It must be noted that although a discriminated-schema is equivalent in 
structure to an array-type, it never the same (in the sense of type com- 
patibility). Moreover, two discrimina.ted-schemas that specify the same 
discriminant -values are not the same. In the following fragment V2 and V3 
have the same type, and V4, V6 'and V7 have the same type. 



type 




Tl 


= SmallVect(3); 


T2 


= SmallVect (3); 


T3 


= Tl; 


var 




VI 


: SmallVect (3); 


V2,V3 


: SmallVect (3); 


V4 


: Tl; 


V5 


: T2; 


V6 


: Tl; 


V7 


: T3; 



Modify the production in section 6.6.3.1 



formal -parameter-section = 

value-parameter-specification | 
variable-parameter-specification | 
constant-parameter-specification | 
procedural-parameter-specification | 
functional-parameter-specification . 

Effect 

This introduces constant -parameter-specification. 



Modify the production in section 6.G.3.1 

variable-parameter-specification = 
"var" identifier- list 
(rype-identifier | schema-identif iter) . 



Effect 

The modified production stares that a variable may be passed into a proce- 
dure or function whose type-denoter is a member of a schema. When a 
schema- identifier is specified, then the parameter may be of any type 
which is a member of the schema. 



Add this production to section 6.6.3.1 

constant -parameter-specification = 

"const" identifier-list ":" schema-identifier . 



Effect 

A constant-parameter-specification is permitted only to be used with 
schemas and permits literal character-strings to be passed efficiently to 
a procedure or function. It also permits variables which are array-schemas 
to be passed as "read-only" variables. It should be possible to extend 
this concept to other types in the future if it found to be desirable. 



Add this to the text of section 6.6.3.1 

The occurrence of an identifier in in the identifier-list of a 
constant -parameter shall constitute its defining point as a 
read-only-variable for the region that is the block, if any, of which it 
is a formal -parameter. 

Effect 

All parameters that are specified with the constant mechanism are identi- 
fied as being read-only varaibles, this permits them to be limited to 
being factors withim the block. 



Add to section 6.6.3.3 

If the formal parameters are specified in a variable- 
parameter-specification in which there is a schema-identifier, the type 
possessed by the actual-parameter shall be a discriminated-schema desig- 
nating the same schema-identif ier as the formal parameter or the actual- 
parameter shall be itself a parameter that was specified with the same 
schema-identifier; and the type possessed by the formal -parameter shall 
be distinct from any other type. 

Effect 

This states that a formal parameter that was declared with a schema will 
only permit the actual parameter to be of type which is part of the same 
schema. A formal -parameter which is a schema may in turn be passed to as a 
variable-parameter utilizing the same schema. 

If the form of the parameter list includes an identifier-list, then all 
the actual parameters must be of the same type: this is true for schemas 
as well as other types. 

The following example adds two vectors, element by element, and returns 
the result in the first parameter. 



procedure AddVectors (var A,B,C : SmallVect); 
var 

i : natural; 
begin 

for i := 0 to B.HighBoxind do 
A[i] := B[i] + C[i] 

end; 



Add a section between 6.6.3.3 and 6.6.3.4 

6.6.3.y Constant parameters. The actual -parameter shall be an expression. 
The formal parameters that occur in a single 

constant-parameter-specification shall possess an array-type which is 
distinct from any other type. The type possessed by the actual -parameter 
shall be a discriminated-schema designating the same schema-identifier as 
the formal parameter or the actual -parameter shall be itself a parameter 
that was specified with the same schema-identif ier ; or the actual- 
parameter must be a string-type and the formal parameter must designate a 
string-schema. 

For an actual -parameter that denotes a variable-access, there shall be no 
assigning-reference during the activation of the block of procedure or 
function to the actual -parameter. 



Effect 



This introduces a parameter mechanism into Pascal that permits may not be 
altered during the activation of the associated procedure or function. Any 
expression may be specified by the actual parameter, however the only 
expression that is not a variable-access will be a string literal. Thus, 
the mechanism achieves not only protection of the actual -parameter but 
also permits literal strings to be specified. 

The method of passing the parameter may be chosen by the implementation, 
one suitable method may by passing an indirect reference in the parameter 
list. 



Modify the production in 6.7 for a factor 

factor = variable-access | unsigned-constant | 

function-designator | set -cons tractor ( 

expression *')" j "not" factor | 

schema-discriminant | read-only-variable . 

schema-discriminant = parameter- identifier 
discriminant -identifier . 

read-only-variable = variable-access , 
Effect 

Addition to factor is used to indicate that a factor may also be a 
s chema-dis criminant . 



Add the production in 6.7 for a schema-discriminant 

schema-discriminant = variable-access 
"." discriminant-identifier 



Effect 

A schema-discriminant is used to determine that" actual -discriminants of 
the the actual -parameter . Because a factor can never appear as a target of 
an assignment, the discriminant may never be altered. The value of the 
discriminant could be thought of as a "read-only" value .associated with 
the variable (or parameter) . 



Example 



const 

MaxMatrix = 100; 

typfe 

Positive = 1. .MaxMatrix; 

Matrix(M,N : Positive) = 

array[ 1. .M, 1. .N ] of Real; 

SquareCLen ; Positive) = Matrix(L,L); 

procedure Transpose ( var M : Square ); 
var 

I, J : Positive; 
R : Real; 
begin 

for I := M.Len downto 2 do 
for J := I-l downto 1 do 
begin 

R := M[I,J] 
M[I,J] := M[J,I] 
M[J,I] := R 
end 

end; 



IMPLEMENTATION NOTES ONE PURPOSE COUPON 

DATE 

IMPLEMENTOR/MAINTAINER/DISTRIBUTOR (* Give a person, address and phone number. *) 



MAC H I IM E / S YSTE M CO N F I G U R ATI O IM (* Any known limits on t/ie configuration or support software required, e.g. 

operating system. *) 



DISTRIBUTION {* Who to as/(, how it comes, in what options, and at what price. *J 



DOCUMEIMTATION f* What is available and where. *) 



IVIAIIMTENANCE (* Is it unmaintained, fully maintained, etc? *) 



STAIM DARD {* How does it measure up to standard Pascal? Is it a subset? Extended? How. *) 



IVI E ASU R E IVI E IMTS r Of its speed or space. *) 



R E LI ABI LITY (* Any information about field use or sites installed. *) 



D EVE LOPMENTMETHOD (* How was it developed and what was it written in? *) 



LIBRARY SUPPORT (* Any other support for compiler in the form of linkages to other languages, source libraries, etc. *J 



(FOLD HERE) 



PLACE 
POSTAGE 
HERE 



Bob Dietrich 
M.S. 92-134 
Tektronix, Inc. 
P.O. Box 500 
Beaverton, Oregon 97077 
U.S.A. 



(FOLD HERE) 



NOTE: Pascal News publishes all the checklists it 
gets. Implementors should sfend us their checklists 
for their products so the thousands of committed 
Pascalers can judge them for their merit. Otherwise 
we must rely on rumors. 



Please feel free to use additional sheets of paper. 



IMPLEMENTATION NOTES ONE PURPOSE COUPON 



POLICY: PASCAL USERS GROUP (15-Sep-80) 



The Pascal User's Group (PUG) promotes the use of the programming 
language Pascal as well as the ideas behind Pascal through the 
vehicle of Pascal News . PUG is intentionally designed to be non 
political, and as such, it is not an "entity" which takes stands on 
issues or support causes or other efforts however well-intentioned. 
Informality is our guiding principle; there are no officers or 
meetings of PUG. 

The increasing availability of Pascal makes it a viable alternative 
for software production and justifies its further use. We all 
strive to make using Pascal a respectable activity. 

Anyone can join PUG, particularly the Pascal user, teacher, 
maintainor, implementor, distributor, or just plain fan. 
Memberships from libraries are also encouraged. See the 
ALL-PURPOSE COUPON for details. 



Facts about Pascal, THE PROGRAMMING LANGUAGE: 

Pascal is a small, practical, and general-purpose (but not all-purpose ) 
programming language possessing algorithmic and data structures to aid 
systematic programming. Pascal was intended to be easy to learn and read by 
humans, and efficient to translate by computers. 

Pascal has met these goals and is being used successfully for: 

* teaching programming concepts 

* developing reliable "production" software 

* implementing software efficiently on today's machines 

* writing portable software 

Pascal implementations exist for more than 105 different computer systems, and 
this number increases every month. The "Implementation Notes" section of 
Pascal News describes how to obtain them. 

The standard reference and tutorial manual for Pascal is: 

Pascal - User Manual and Report (Second, study edition) 
by Kathleen Jensen and Niklaus Wirth. 

Springer-Verlag Publishers: New York, Heidelberg, Berlin 
1978 (corrected printing), 167 pages, paperback, $7.90. 

Introductory textbooks about Pascal are described in the "Here and There" 
section of Pascal News. 

The programming language, Pascal, was named after the mathematician and 
religious fanatic Blaise Pascal (1623-1662). Pascal is not an acronym. 

Remember, Pascal User's Group is each individual member's group. We currently 
have more than 3500 active members in more than 41 countries, this year Pascal 
News is averaging more than 100 pages per issue. 



Purpose: 



Membership : 



